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.
