On 07/30/2018 12:57 AM, Richard Biener wrote:
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.
As I explained, it's unhelpful for two people to making changes
to the same code at the same time, especially when one is undoing
the other one's changes. I have made it clear that I am working
in this area -- I welcome and address valid feedback but I can't
very well do that while someone is compromising my work.
I appreciate test cases and suggestions for improvements but
please avoid making changes to this code while I'm working on
it. It is not helpful.
Martin
