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
