From: 046-301-5902@kylheku.com
On 2026-01-10, Michael S wrote:
> On Fri, 9 Jan 2026 20:14:04 -0000 (UTC)
> Kaz Kylheku <046-301-5902@kylheku.com> wrote:
>
>> On 2026-01-09, Michael S wrote:
>> > On Fri, 09 Jan 2026 01:42:53 -0800
>> > Tim Rentsch wrote:
>> >
>> >>
>> >> The important thing to realize is that the fundamental issue here
>> >> is not a technical question but a social question. In effect what
>> >> you are asking is "why doesn't gcc (or clang, or whatever) do what
>> >> I want or expect?". The answer is different people want or expect
>> >> different things. For some people the behavior described is
>> >> egregiously wrong and must be corrected immediately. For other
>> >> people the compiler is acting just as they think it should,
>> >> nothing to see here, just fix the code and move on to the next
>> >> bug. Different people have different priorities.
>> >>
>> >
>> > I have hard time imagining sort of people that would have
>> > objections in case compiler generates the same code as today, but
>> > issues diagnostic.
>>
>> If false positives occur for the diagnostic frequently, there
>> will be legitimate complaint.
>>
>> If there is only a simple switch for it, it will get turned off
>> and then it no longer serves its purpose of catching errors.
>>
>> There are all kinds of optimizations compilers commonly do that could
>> also be erroneous situations. For instance, eliminating dead code.
>>
>
>
>
> I am not talking about some general abstraction, but about specific
> case.
> You example is irrelevant.
> -Warray-bounds exists for a long time.
> -Warray-bounds=1 is a part of -Wall set.
In your particular example, it is crystal clear that the "return 0"
statement is elided away due to being considered unreachable, and the
only reason for that can be undefined behavior, and the only undefined
behavior is accessing the array out of bounds.
The compiler has decided to use the undefined behavior of the OOB array
access as an unreachable() assertion, and at the same time neglected to
issue the -Warray-bounds diagnostic which is expected to be issued for
OOB access situations that the compiler can identify.
No one can claim that the OOB situation in the code has escaped
identification, because a code-eliminating optimization was predicated
on it.
It looks as if the logic for identifying OOB accesses for diagnosis is
out of sync with the logic for identifying OOB accesses as assertions of
undefined behavior.
In some situations, a surprising optimization occurs not because of
undefined behavior, but because the compiler is assuming well-defined
behavior (absence of UB).
That's not the case here; it is relying on the presence of UB.
Or rather, it is relyiing on the absence of UB in an assinine way:
it is assuming that the program does not reach the out-of-bounds
access, because the sought-after value is found in the array.
But that reasoning requires awareness of the existence of the
out-of-bounds access.
That's the crux of the issue there.
There is an unreachable() assertion in modern C. And it works by
invoking undefined behavior; it means "let's have undefined behavior
in this spot of the code". And then, since the compiler assumes
behavior is well-defined, assumes that that statement is not reached,
nor anything after it, and can eliminate it.
The problem is that an OOB array access should not be treated
as the same thing, as if it were unreachable(). Or, rather, no,
sure it's okay to treat an OOB arrary access as unreachable() --- IF
you generate the diagonstic about OOB array access that you
were asked to generate!!!
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
