Florian Weimer <fweimer@xxxxxxxxxx> 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
