[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How can Autoconf help with the transition to stricter compilation de
Re: How can Autoconf help with the transition to stricter compilation defaults?
Fri, 11 Nov 2022 22:40:21 -0500
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Florian Weimer <firstname.lastname@example.org> 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.
Re: How can Autoconf help with the transition to stricter compilation defaults?, Bob Friesenhahn, 2022/11/10
Re: How can Autoconf help with the transition to stricter compilation defaults?, Aaron Ballman, 2022/11/10