Follow-up Comment #6, sr #110530 (project autoconf):
[comment #5 comment #5:]
> I don't know whether there was an alternative that Apple did not pursue in
which implicit function declarations could have been allowed.
Sure there was an alternative. They could have made
-Wno-error=implicit-function-declaration the default.
> If you disagree with them, you may file a bug report
I don't use Apple software so it's not likely they'll listen to any bug report
I might file (possibly they won't even let me file one). If this problem
affects you, I suggest you file a bug report; if you're an Apple customer they
might listen to you.
> according to Apple, if you allow implicit function declarations, you risk
creating a program ... that on Apple Silicon processors either crashes or
behaves incorrectly.
Of course. But this has been true on pretty much every platform, ever since
people started using function prototypes, introduced in C89 over three decades
ago. But this issue does not affect Autoconf's usage. Autoconf is merely
trying to find whether the function exists; it's not trying to call the
function.
> Do not use -Wno-error=implicit-function-declaration to attempt to circumvent
this protection.
This advice sounds incorrect to me.
Please give a specific example of where using
-Wno-error=implicit-function-declaration would hurt on macOS, in the sense
that it would break Autoconf's use of that flag to detect whether a function
exists or is declared.
For example, to test whether getdtablesize exists, 'configure' tries to
compile and link a program that is like this:
char getdtablesize ();
int main () { return getdtablesize (); }
It doesn't run the program; it merely links it. If the link succeeds, the
function exists. Why would compiling with
-Wno-error=implicit-function-declaration break this?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?110530>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
