On 07/04/2018 11:32 AM, Martin Sebor wrote: > On 07/03/2018 08:33 PM, Jeff Law wrote: >> >>> >>> But since the number of warnings here hasn't changed, the ones >>> in GCC logs predate my changes. So updating the tests seems >>> like an improvement to consider independently of the patch. >> Agreed. I'm still wary of proceeding given the general concerns about >> configure tests. It's good that GCC's configury bits aren't affected, >> but I'm not sure we can generalize a whole lot from that. > > So what's the next step? I'm open to relaxing the warning > so it only triggers with -Wall or -Wextra and not by default > if that's considered necessary. I'm not sure :-) The problem is we have notable potential to break things and do so in ways that are going to be painful to find.
Having them only turn on for -Wextra might be an compromise position. But even if we do that I don't really see how we take the next step (ie, adding it to Wall). > > At the same time, the instances of the warning we have seen > have all been issued for the configure tests for years and > we have not seen any new instances of it as a result of > this change, so the concern that the patch might lead to some > more while at the same time accepting the ones we know about > doesn't make sense to me. Again, I don't think we can generalize much from the GCC autoconf scripts and the failure modes are going to be extremely painful to track down to this change. While we have this concern with every new warning or enhancements to existing warnings, this specific instance is worse because of how it interacts with relatively common configury code. Jeff
