On February 21, 2018 4:25:14 AM GMT+01:00, Jeff Law <l...@redhat.com> wrote: >On 02/20/2018 04:59 PM, Martin Sebor wrote: >>> It would help if you explained why you think it is a good idea >>> ignoring the other phi arguments if you have one (or more) where you >can >>> determine length. >> >> It's a heuristic that was meant just for the -Wformat-overflow >> warning. When making decisions that affect code generation it's >> obviously not correct to ignore the possibility that unknown >> arguments may be shorter than the minimum or longer than >> the maximum. The fuzzy argument was meant to differentiate >> between two got but I forgot about it when I added the fix >> for PR 83671. >> >> For GCC 8 I don't have a preference for how to fix this as long >> as it doesn't regress the warning tests. >> >> I think the ultimate solution (for GCC 9) may be to either >> disable the heuristic for code generation purposes (e.g., via >> another argument/flag) or provide a pointer argument to indicate >> to the caller that the minimum is based on known strings, and that >> the real minimum may be zero. >I'm still getting refamiliar with this code. But one thing that jumps >out immediately is how much this reminds me of the discussion we had >around 77608 -- where I argued that returning something that was not >conservatively correct was just asking for long term problems. > >I realize we're talking about different routines, but the concerns are >the same -- when we return something that is not conservatively correct >it's easy for someone to mistakenly use those results for code >generation purposes. > >The fuzzy stuff is in there to reduce the false positive rates and >we're >not *supposed* to be using fuzzy results for code generation purposes, >but as I argued in 77608, it's easy to miss. > >I'll reiterate my desire to make this kind of mistake harder to make.
Can you simply provide that interface via a separately named API rather than overloading one that is also supposed to be used by optimization? Richard. >Jeff