Remove K&R function declaration from flex.

[ericonr]

A common header is a more adequate long term solution for this purpose. This commit only intends to fix a compilation error reported on the mailing list [1].

[1] https://epics.anl.gov/tech-talk/2023/msg00050.php

[mdavidsaver]

So far we have tried to avoid further patching of our bundled forks of flex and yacc. That said, the code has already been extensively patch, and this change is trivial.

Before applying, I'd like to understand if some newer C compiler really has started to reject K&R syntax by default.

fyi. My abandoned attempt to update the bundled flex/yacc: https://github.com/mdavidsaver/epics-base/tree/lexyacc-update

[ericonr]

Before applying, I'd like to understand if some newer C compiler really has started to reject K&R syntax by default.

That's fair, I am quite curious about it myself. A C++ compiler being used (as you mentioned in tech-talk) crossed my mind, but it seemed unlikely.

Waiting for confirmation that this fixes all the compilation errors might be a good idea as well. I couldn't find a good way to warn on K&R usage when actually passing arguments that doesn't also print warnings for all C functions that are declared with type function(); instead of type function(void); (tried -Wstrict-prototypes).

[AppVeyorBot]

✅ Build EPICS Base 7 base-7.0-740 completed (commit d621cec122 by @ericonr)

[mdavidsaver]

... It was just the g++ compiler; for some reason symlink was not working. ...

https://epics.anl.gov/tech-talk/2023/msg00090.php

[ericonr]

Is it reasonable to support building that code as C++?
I think the commit message is generic enough that it wouldn't have to be changed, either way? Unless you'd like for the last response to be added to it.

[mdavidsaver]

Is it reasonable to support building that code as C++?

To my mind, no. To do so does not produce the same output. eg. with C++ symbol name mangling.

[anjohnson]

Core Group: Not a bug, users need to use a C compiler to compile .c code.