[sr #110530] Missing #include <string.h> in AC_FUNC_MEMCMP

[Ryan Schmidt]

Follow-up Comment #7, sr #110530 (project autoconf):

I don't really want to continue this discussion, and I'm not going to file bug
reports with another company on your behalf arguing for a change that I don't
advocate. I'll just explain that on arm64 processors, the compiler generates
different machine code depending on whether a function is variadic or not. It
affects whether arguments go on the stack or in registers. This is in contrast
to x86_64 processors where the arguments go in the same place regardless
(unless the function has a very large number of arguments which is uncommon).
The compiler must therefore know in advance what type of function it is so it
can write the correct machine code, and the way that it knows that is by
seeing the function prototype, so it is imperative that one be provided, e.g.
by including the right header.

I would not say that Apple "cares" or "doesn't care" about GNU tools; instead,
I would say that Apple wished to improve the performance of the computers they
sell by switching from Intel processors to in-house arm64 processors, and they
made a change to their toolchain that would ensure developers are notified if
they use a programming technique that could cause problems on the new
architecture. You are proposing that this helpful compile-time notification
should be disabled; I don't think that's a good idea since debugging runtime
crashes and misbehavior is more difficult than noticing and correcting a
compile-time error.

Your getdtablesize example is inapplicable since a prototype is provided and
it would not be affected by enabling or disabling the
implicit-function-declaration error. However there may be other types of
checks performed by some autoconf configure scripts that actually link and run
a program in order to make some determination. These programs might crash or
misbehave and thus make the wrong determination on arm64 if implicitly
declared functions are involved.

Instructing the user to add -Wno-error=implicit-function-declaration to CFLAGS
when running configure would be bad because those CFLAGS would be recorded and
used during the build where they could cause the aforementioned problem in the
software that gets built and installed.

As you point out, function prototypes have been available since C89, and have
been required since C99, so everyone has had ample time to modify their code
to use them; fighting for the continued right to neglect to specify something
that has been required for over 20 years seems fruitless.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110530>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/