From: david.brown@hesbynett.no
On 02/01/2026 17:51, highcrew wrote:
> On 1/2/26 10:31 AM, David Brown wrote:
>> However, it /does/ make sense to ask whether the compiler could have
>> been more helpful in pointing out your mistake - and clearly, in
>> theory at least, the answer is yes.
> > [...]
>
> Thanks for the clarification.
>
> Yes, I'm exactly wondering if the compiler shouldn't reject that code
> to begin with. I'm not expecting to enter wrong code and get a
> working program. That would be dark magic.
>
> So you are basically confirming what I inferred from Waldek Hebisch's
> answer: it is actually quite hard for the compiler to spot it. So we
> live with it.
I think it is fair to say that if it were easy to detect this case
within the structure of existing compilers, they would do so already.
The fact that both gcc and clang fail to produce warnings, despite
having significant differences in their internal structures and the
details of their passes, shows that it is not as easy at it might
appear. And James has explained why the C standards can't make
detection of this kind of fault a language requirement.
But it is still worth reporting the simple test case to gcc (and clang)
to see if they are able to improve their warnings.
>
>> I had a little look in the gcc bugzilla, but could not find any issue
>> that directly matches this case. So I think it is worthwhile if you
>> file it in as a gcc bug. (It is not technically a "bug", but it is
>> definitely an "opportunity for improvement".) If the gcc passes make
>> it hard to implement as a normal warning, it may still be possible to
>> add it to the "-fanalyzer" passes.
>
> Erm... I will considering filing an "opportunity for improvement"
> ticket then, thank you.
"Opportunity for improvement" tickets are the driving force behind a lot
of open source software features, so please do file it. Post the
bugzilla link here once you get some feedback - it would be good to see
if there is likely to be an improvement in the warnings.
>
>>> There's plenty of documentation, articles and presentations that
>>> explain how this can make very efficient code... but nothing
>>> will answer this question: do I really want to be efficiently
>>> wrong?
>>
>> You are asking if you want the generated code to be efficiently wrong
>> or inefficiently wrong?
>
> I was asking if it is reasonable to accept as valid a program which
> is wrong, and make it optimized in its wrong behavior.
>
Yes, it is. That is perhaps unfortunate from the programmers'
viewpoint, but "garbage in, garbage out" is unavoidable.
> What I could not grasp is the difficulty of the job.
> To quote your own words:
>
> > Sometimes that means things can appear simple and obvious to the user,
> > but would require unwarranted effort to implement in the compiler."
>
>> You can also make use of run-time sanitizers that are ideal for
>> catching this sort of thing (albeit with an inevitable speed overhead).
>>
>>
>
> Yes, I'm aware of this instruments, but I'm not very knowledgeable about
> it. I'd like to learn more, and I'll need to spend time doing so.
>
The tools here can be useful. Of course it is best when you can find
bugs earlier, at the static analysis stage (I am a big fan of lots of
compiler warnings), but the "-fsanatize" options are the next step for a
lot of development. They are of limited value in my own work (small
embedded systems - there's often no console for log messages, and much
less possibility of "hardware accelerated" error detection such as
creative use of a processor's MMU), but for PC programming they can be a
great help.
>
> Thanks!
>
It's been a good thread - on-topic, interesting discussion, people have
got a better understanding of a few things, there's an opportunity to
contribute to better C development tools, and no flames. I look forward
to your next question!
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
