This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Make strlen range computations more conservative
One other example I have found in one of the test cases:
if (strlen(&c) != 0) abort();
this is now completely elided, but why?
Because the only string that can be stored in an array of one
element is the empty string. Expanding that call to strlen()
is in all likelihood going to result in zero. The only two
cases when it doesn't are invalid: either the character is
uninitialized (GCC may not see it so it may not warn about
it), or it is initialized to a non-zero value (which makes
it not a string -- I have submitted an enhancement to detect
a subset of these cases). The cases where the user expects
to be able to read past the end of the character and what
follows are both exceedingly unlikely and also undefined.
So in my view, it is safer to fold the call into zero than
Is there a code base where
that is used? I doubt, but why do we care to eliminate something
stupid like that? If we would emit a warning for that I'm fine with it,
But if we silently remove code like that I don't think that it
will improve anything. So I ask, where is the code base which
gets an improvement from that optimization?
Jonathan suggested issuing a warning in this case. That
sounds reasonable to me, but not everyone is in favor of
issuing warnings out of the folder. (I'm guilty of having
done that in a few important cases despite it.) I am fully
supportive of enhancing warnings to detect more problems,
but I am opposed to gratuitously removing solutions that
have been put in after a great deal of thought, without as
much as bring them up for discussion.
This work concentrates mostly on avoiding to interfere with code that
actually deserves warnings, but which is not being warned about.
Then help by adding the missing warnings. It will help drive
improvements to user code and will ultimately lead to greater
efficiency. Dumbing down the analyses and accommodating
undefined code is not a good way forward. It will only lead
to a kludgy compiler with hacks for this or that bad practice
and compromise our ability to implement new optimizations (and
detect more bugs).