This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Aug 03, 2018 at 03:16:41PM -0600, Jeff Law wrote:
> On 07/31/2018 12:33 AM, Jakub Jelinek wrote:
> > On Mon, Jul 30, 2018 at 10:01:38PM -0600, Martin Sebor wrote:
> >>> We do not want to change what is currently accepted by the
> >>> front end. period.
> >>
> >> On whose behalf are you making such categorical statements?
> >> It was Jakub and Richard's suggestion in bug 86714 to reject
> >> the undefined excessive initializers and I happen to like
> >> the idea.  I don't recall anyone making a decision about what
> > 
> > It was not my suggestion and it is already rejected with -pedantic-errors,
> > which is all that is needed, reject it in pedantic mode.
> > Otherwise there is a warning emitted by default which is enough.
> But I think that's a mistake.  I think a hard error at this point is
> warranted and the safest thing to do.

The normal behavior when it isn't an error is that the initializer is
truncated.  That is what happens if I use
struct S { char a[4]; };
struct S r = { "abc" };
struct S s = { "abcd" };
struct S t = { "abcde" };

C says that in the s.a initializer is actually just 'a', 'b',
'c', 'd' rather than 'a', 'b', 'c', 'd', '\0', so there is a silent
truncation in the language naturally, so the extension that truncates even
more with a warning enabled by default is IMHO natural and doesn't need to
be more pedantic.  We've always truncated, so there should be no surprises.

> > The suggestion was that if we don't reject (and no reason to change when we
> > reject it), that we handle it right, which is what your optimization broke.
> But it's not always clear what is right.  That's my concern.  If we had
> rules which were clearly right, then applying those rules and continuing
> is much more reasonable.

Perhaps we haven't written them down, but we've always behaved that way.
clang also truncates with a warning enabled by default, only rejects it like
gcc with -pedantic-errors.  So does icc.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]