> Am 23.05.2026 um 11:28 schrieb Jonathan Wakely via Gcc <[email protected]>:
>
> On Sat, 23 May 2026 at 00:09, Siddhesh Poyarekar wrote:
>> I do think though that adding it to -Wextra is pointless and maybe just
>> keeping them independent is sufficient. We have projects like the
>> OpenSSF C/C++ hardening guide[1] that should plug these options to
>> people who would like to see these warnings. That and maybe enable them
>> in -fhardened, although currently that flag only flips options that
>> affect codegen (IIRC).
>
> That could actually make sense. -fhardened enables
> -D_GLIBCXX_ASSERTIONS and so the std::string and std::vector
> preconditions are all checked, which makes most of the "you definitely
> have a bug here!" conditions unreachable. That would avoid some of the
> most frustrating (and frequently reported) false positives.
>
>
>> Could we however wait until Andrew MacLeod works through porting the
>> pointer-query stuff to pranges and then decide? It won't bring the
>> false positives down to zero, but maybe improve range visibility enough
>> (and maybe Andrew cleans more things up as he works on it!) for them to
>> be less problematic than what they are today.
>
> Andrew already responded to this part, but I'd like to see them
> disabled *first*, then re-enabled if future work shows they're useful
> again.
One thing that might be worth exploring is aggressively using path ranger to
prove (all?) paths to a diagnostic we are about to emit are not taken. It also
gives us more precise paths to show with diagnostic path.
This really shows we’re doing static analysis here, but in the poorest form
with only taking into account what is explicitly exposed in the IL, relying
fully on optimization to prune unreachable paths.
Richard
>
> And if they're fine for C, keep them on for C. I don't care about
> that. For C++ they're a big problem.
