[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: [sr #110530] Missing #include <string.h> in AC_FUNC_MEMCMP
Date: Tue, 31 Aug 2021 18:56:09 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

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

[comment #7 comment #7:]

> Your getdtablesize example is inapplicable since a prototype is provided
Oh, good point. As Zack mentioned, the
-Wno-error=implicit-function-declaration issue is therefore irrelevant to the
current bug report.

At the risk of adding yet more-irrelevant info to this bug report I will reply
to some of your other points.

> I'll just explain that on arm64 processors, the compiler generates different
machine code depending on whether a function is variadic or not.
Fine, but that's true for many architectures including x86-64. The idea that
this incompatibility was forced by machine architecture is a red herring.

> 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).
No, x86-64 is like most other architectures, in that if you omit function
prototypes your programs can go way wrong. For example:

int foo (float);
// 'bar' has the same API, but it's omitted here.
int main (void)
  foo (0);
  bar (0);

The x86-64 machine code for the call to 'foo' is quite different from that of
the call to 'bar', and the latter call does not work on x86-64. (It happened
to work on some older platforms, but those days are long gone.)

> You are proposing that this helpful compile-time notification should be
Not at all. It's a good thing to generate compile-time notifications for this
problem, and GCC regularly does so on GNU/Linux. I'm merely objecting to the
notifications breaking the compilations; this is an incompatible change to
clang that is likely to cause more real-world problems than it cures.

> 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.
Not if they're merely testing for function existence.

> 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
That's fine if you're writing a single test for a particular function. It's
not fine if you're writing a generic Autoconf macro intended for checking
arbitrary functions. To cater to this new -Werror business, any such macro
would require its user to declare the functions in question, which is a
tedious and error-prone process that is likely more trouble than it's worth.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]