This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] fold more string comparison with known result (PR 90879)
On 8/12/19 7:40 AM, Michael Matz wrote:
Hi,
On Fri, 9 Aug 2019, Martin Sebor wrote:
The solution introduced in C99 is a flexible array. C++
compilers usually support it as well. Those that don't are
likely to support the zero-length array (even Visual C++ does).
If there's a chance that some don't support either do you really
think it's safe to assume they will do something sane with
the [1] hack?
As the [1] "hack" is the traditional pre-C99 (and C++) idiom to
implement flexible trailing char arrays, yes, I do expect all existing
(and not any more existing) compilers to do the obvious and sane thing
with it. IOW: it's more portable in practice than our documented
zero-length extension. And that's what matters for the things compiled by
the host compiler.
Without requiring C99 (which would be a different discussion) and a
non-existing C++ standard we can't write this code (in this form) in a
standard conforming way, no matter what we wish for. Hence it seems
prudent to use the most portable variant of all the non-standard ways, the
trailing [1] array.
There are a few reasons why these legacy C idioms should be
replaced with better/newer/safer alternatives.
First, with two C revisions since C99 and with support for
superior alternatives widely available, pre-C99 idioms have less
and less relevance.
Second, since most of GCC requires a C++98 compiler to compile,
ancient C code needs to adjust to the more strict C++ requirements.
As C++ evolves, dependencies on legacy extensions like this one
make it increasingly difficult to upgrade to newer revisions of
the standard. C++ 11 already requires compilers to reject
undefined behavior in constexpr contexts, including accesses
to arrays outside of their bounds. Once GCC adopts C++ 11 it
won't be able to make use of constexpr with code that relies
on the hack.
Third, the safest and most secure approach to dealing with past-
the-end accesses is to diagnose and prevent them. Accommodating
code that disregards the array bounds compromises this goal. This
is evident from the gaps in _FORTIFY_SOURCE and -Wstringop-overflow
that other compilers like Clang and ICC don't suffer from(*). It's
in everyone's best interest to proactively drive them to extinction
and replace them by safer alternatives that let compilers distinguish
the intentional accesses from accidental ones. It not only makes it
easier to find bugs but also emit more efficient object code.
Martin
PS Unlike GCC, both Clang and ICC diagnose past-the-end accesses
to trailing arrays with more than one element. They do recognize
the struct hack even in C++ and, outside constexpr contexts, avoid
diagnosing past-the-end accesses to trailing one-element arrays.
This isn't so much an issue today because neither allows statically
initializing struct objects with such arrays to more elements than
the bound specifies. But it will likely change when the C++
proposal for constexpr functions to use new expressions is adopted
(P0784R1).