How can Autoconf help with the transition to stricter compilation defaults?

2022-11-10 Thread Zack Weinberg via cfe-commits
I’m the closest thing Autoconf has to a lead maintainer at present.

It’s come to my attention (via https://lwn.net/Articles/913505/ and
https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
Clang both plan to disable several “legacy” C language features by
default in a near-future release (GCC 14, Clang 16) (see the Fedora
wiki link for a list).  I understand that this change potentially
breaks a lot of old dusty code, and in particular that
Autoconf-generated configure scripts use constructs that may *silently
give the wrong answer to a probe* when a stricter compiler is in use.

Nobody has a whole lot of time to work on Autoconf at present, but I
would like to ask, anyway, what Autoconf could potentially do to make
this transition easier.  I’m already aware that the test code Autoconf
2.71 uses to probe for C89/C99/C11 support is broken; this has been
fixed in development trunk to the extent it is possible for me to test
it with GCC 12 (commit:
).
Several other places using K&R function definitions and/or
unprototyped function declarations (including the ubiquitously used
AC_CHECK_FUNC) have also been fixed on trunk,
.
Changes to handle C23 built-in ‘bool’ better are under development but
the design has not yet been finalized.

The biggest remaining (potential) problem, that I’m aware of, is that
AC_CHECK_FUNC unconditionally declares the function we’re probing for
as ‘char NAME (void)’, and asks the compiler to call it with no
arguments, regardless of what its prototype actually is.  It is not
clear to me whether this will still work with the planned changes to
the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
triggered by ‘extern char memcpy(void);’ (or any other standard
library function whose prototype is coded into the compiler) and this
already causes problems for people who run configure scripts with
CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
have to build a comprehensive list of library functions into Autoconf,
mapping each to either its documented prototype or to a header where
it ought to be declared; in the latter case we would also have to make
e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
sys/socket.h netdb.h]) which might mess up configure scripts that
aren’t expecting headers to be probed at that point.

How important do you think it is for this to be fixed?

Are there any other changes you would like to see in a near-future
Autoconf 2.72 in order to make this transition easier?

zw

p.s. GCC and Clang folks: As long as you’re changing the defaults out
from under people, can you please also remove the last few predefined
user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
-std=gnuXX modes?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-11 Thread Zack Weinberg via cfe-commits
Florian Weimer  writes:
> based on a limited attempt to get this fixed about three years
> ago, I expect that many of the problematic packages have not had their
> configure scripts regenerated using autoconf for a decade or more.  This
> means that as an autoconf maintainer, you unfortunately won't be able to
> help us much.

I’m sadly not surprised.

This is definitely more work than I can see myself doing on a volunteer
basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
cherry pick the changes needed to support the newer compilers (and
also newer Perl and Bash and M4) is a thing that could happen.

> Thanks, these changes are going to be helpful to get a clean run from
> our Fedora tester.

Autoconf’s own test suite is sadly not very thorough.  If you find more
problems I will prioritize them.

> Once you include the header, you also need to know function parameters,
> otherwise you won't be able to form a valid call.

You can assign to a function pointer variable if you know the complete
type signature, which is desirable for other reasons (see reply to Rich).
Needing to know how to form argument *values* could be much more trouble,
but I don’t think it should be necessary.

>> p.s. GCC and Clang folks: As long as you’re changing the defaults out
>> from under people,
>
> Hmph, I wouldn't frame it this way.  We are aware of GCC's special role
> as the system compiler.  We're trying to upstream the changes to sources
> before flipping the compiler default.  (The burden of being a system
> compiler and all that.)  A 25-year transition period evidently wasn't
> enough, so some effort is still needed.  We may conclude that removing
> these extensions is too costly even in 2024.

I didn’t mean to imply that I disliked any of the changes.  In fact,
with my day job (CS professor) hat on, I am quite looking forward to not
having to warn the kids about these legacy features anymore (we don’t
_teach_ them, but they inevitably use them by accident, particularly
implicit function declarations, and then get confused because ‘cc’ with
no -W options doesn’t catch the mistake).

>> can you please also remove the last few predefined
>> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
>> -std=gnuXX modes?
>
> That's a good point, I'll think about how we can instrument GCC to
> support tracking that.  We won't be able help with -Darm on the Fedora
> side (the AArch64 port doesn't have that, and there's no longer a Fedora
> 32-bit Arm port), but -Dlinux and -Dunix we can help with.

These are also a trip hazard for novices, and the only way to turn them
off is with -std=cXX, which also turns another trip hazard (trigraphs)
*on*… so yeah, anything you can do to help speed up their removal, I
think it’d be worthwhile.

zw
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-12 Thread Zack Weinberg via cfe-commits
Sam James  writes:

>> On 12 Nov 2022, at 03:40, Zack Weinberg  wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support the newer compilers (and
>> also newer Perl and Bash and M4) is a thing that could happen.
>
> I didn't want to ask you to do this because I felt fortunate enough
> you were volunteering to handle 2.72, but this would indeed be a help,
> because then I won't have to try persuade people they should totally upgrade,
> and it should happen naturally enough with distro upgrades.

To be clear, I am *not* volunteering to do this.  It would be
significantly more work than I can carve out the time for.

Whoever does this will need to go through the *entire* list of changes
since the original 2.69 release, to find all of the changes that improve
compatibility with newer versions of tools, disentangle each from any
other changes applied in the same commit, and then do a whole lot of
testing.  It’s tedious, and whoever does it should get paid to do it.
I’m guessing at least one full 40-hour week of work, and you should
budget for three times that, going by how much more work the 2.70
release was than we anticipated.

I can *advise* anyone who takes on the job, and review their changes,
but that’s it.

zw
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-12 Thread Zack Weinberg via cfe-commits
Wookey  writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more.  This
>> means that as an autoconf maintainer, you unfortunately won't be able to
>> help us much.
>
> We changed the default in debian to re-autoconf on build a few years
> ago precisely so that changes in the tools (particularly new arch
> support) were picked up even by code that was not being re-released or
> released without autofoo updates.  This has worked remarkably well.
>
> So changes in the tools will get used, at least in that context, which
> includes a fairly hefty pile of crufty old code. I have no feeling for
> how many packages are actually affected by this. Is there a quick way to test?

In the run-up to Autoconf 2.70 I got Lucas to do a Debian archive
rebuild and mass bug filing, so, look through Debian packages for
patches being carried for configure.ac and/or bundled .m4 files?

zw
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-15 Thread Zack Weinberg via cfe-commits
On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
>> 
>> Although there will be problems with people who run "./configure 
>> CFLAGS='-Werror'", that sort of usage has always been problematic and 
>> unsupported by Autoconf, so we can simply continue to tell people "don't do 
>> that".
>> 
>
> Is there somewhere in the autoconf docs we actually say this?
>
> I've seen a few instances of folks adding it themselves very
> early in their configure scripts (which is a pain for distros
> anyway) which then ends up affecting the rest.

It's mentioned in the NEWS entry for 2.70: 
https://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS#n170

It should be discussed in the actual manual as well, but I've been reluctant to 
add anything about warnings to the manual as long as Autoconf proper doesn't 
have any support for controlling warnings.

Note that there have been bug reports for cases where running builds with more 
warnings than configure uses (and I think also -Werror), means that configure 
checks spuriously succeed (i.e. configure reports that something is available, 
but then you get compiler errors on the code that tries to use it).  I can't 
remember any concrete examples right now, though.

zw
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-16 Thread Zack Weinberg via cfe-commits
On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it 
> might be justifiable for default Clang to break Autoconf. But so far we 
> haven't seen real-world uses that would justify this pickiness for 
> Autoconf's use of 'char memset_explicit(void);'.

I don't have time this week to really get into this argument but I want to 
point out that I'm generally in agreement with Rich Felker's argument (in 
https://ewontfix.com/13/) that AC_CHECK_FUNC *should not* just probe for 
linkability of a symbol, because:

 - Not including the appropriate headers means that the probe bypasses 
compile-time symbol renaming and therefore probes for *the wrong symbol*, 
potentially causing both false detection and false non-detection (to tie it to 
another subthread, notice that one of the things -D_TIME_BITS=64 triggers (from 
glibc's headers) is enable dozens of __REDIRECT annotations in time.h)

 - Only probing the symbol, and not its type signature, means for instance that 
if the program expects GNU strerror_r but the system provides POSIX strerror_r, 
or vice versa, Autoconf's check will succeed but the program will fail to 
compile (in more subtle cases it might be miscompiled instead)

(N.B. I *don't* agree with the assertion at the bottom of that page that 
"taking explicit action to prevent linking against [symbols intended to be 
exposed for binary compatibility only], involves hacks that are even worse and 
more fragile than what configure is doing" -- yes, it sucks that the toolchain 
support for ELF symbol versioning is still mostly absent, 20 years after the 
concept was introduced, but `asm(".symver __strtod_l_compat, 
strtod_l@SOME_CONCRETE_VERSION_TAG")` is straightforward (if cryptic) and 
robust on all the platforms where it works at all.)

zw
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits