[PATCH] Fix wrong code with truncated string literals (PR 86711/86714)

[Richard Biener]

On Sun, 29 Jul 2018, Martin Sebor wrote:

> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
> > Hi!
> > 
> > This fixes two wrong code bugs where string_constant
> > returns over length string constants.  Initializers
> > like that are rejected in C++, but valid in C.
> 
> If by valid you are referring to declarations like the one in
> the added test:
> 
>     const char a[2][3] = { "1234", "xyz" };
> 
> then (as I explained), the excess elements in "1234" make
> the char[3] initialization and thus the test case undefined.
> I have resolved bug 86711 as invalid on those grounds.
> 
> Bug 86711 has a valid test case that needs to be fixed, along
> with bug 86688 that I raised for the same underlying problem:
> considering the excess nul as part of the string.  As has been
> discussed in a separate bug, rather than working around
> the excessively long strings in the middle-end, it would be
> preferable to avoid creating them to begin with.
> 
> I'm already working on a fix for bug 86688, in part because
> I introduced the code change and also because I'm making other
> changes in this area -- bug 86552.  Both of these in response
> to your comments.
> 
> I would normally welcome someone else helping with my work
> but (as I already made clear last week) it's counteproductive
> to have two people working in the very same area at the same
> time, especially when they are working at cross purposes as
> you seem to be hell-bent on doing.
> 
> > I have xfailed strlenopt-49.c, which tests this feature.
> 
> That's not appropriate.  The purpose of the test is to verify
> the fix for bug 86428: namely, that a call to strlen() on
> an array initialized with a string of the same length is
> folded, such as in:
> 
>     const char b[4] = "123\0";
> 
> That's a valid initializer that can and should continue to be
> folded.  The test needs to continue to exercise that feature.
> 
> The test also happens to exercise invalid/overlong initializers.
> This is because that, in my view, it's safer to fold the result
> of such calls to a constant than than to call the library
> function and have it either return an unpredictable value or
> perhaps even crash.
> 
> > Personally I don't think that it is worth the effort to
> > optimize something that is per se invalid in C++.
> 
> This is a C test, not C++.  (I don't suppose you are actually
> saying that only the common subset between C and C++ is worth
> optimizing.)
> 
> Just in case it isn't clear from the above: the point of
> the test exercising the behavior for overlong strings isn't
> optimizing undefined behavior but rather avoiding the worst
> consequences of it.  I have already explained this once
> before so I'm starting to wonder if I'm being insufficiently
> clear or if you are not receiving or reading (or understanding)
> my responses.  We can have a broader discussion about whether
> this is the best approach for GCC to take either in this instance
> or in general, but in the meantime I would appreciate it if you
> refrained from undoing my changes just because you don't agree
> with or don't understand the motivation behind them.
> 
> Martin
> 
> PS I continue to wonder about your motivation and ethics.  It's
> rare to have someone so openly, blatantly and persistently try
> to undermine someone else's work.

Martin, you are clearly the one being hostile here - Bernd is trying
to help.  In fact his patches are more focused, easier to undestand
and thus easier to review.

Get your feelings about "ownership" under control.

Richard.