Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.std.c
Subject: int n = {{0}};
Date: Thu, 26 Oct 2023 19:57:19 -0700
Organization: None to speak of
Lines: 51
Message-ID: <8734xwkc1c.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="7ab2f2b489eaca4d293095b514b3d94e"; logging-data="2194295"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+q3TKSCKdQccfv9b1qjISK"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:mmEjKILPlZddMkiRuZje73DIVFA= sha1:Zk3eWJlejJe+25qCD/5PJRDn6e0=
Xref: csiph.com comp.std.c:6585

Citations are from N1570 (C11 draft).  I don't think there are any
relevant differences in other editions or drafts of the standard.

Quick summary: Why is
    int n = {{0}};
undefined behavior rather than a constraint violation?

6.7.9 (Initialization) includes a list of constraints, starting with "No
initializer shall attempt to provide a value for an object not contained
within the entity being initialized."

6.7.9p11 says:

    The initializer for a scalar shall be a single expression,
    optionally enclosed in braces. The initial value of the object is
    that of the expression (after conversion); the same type constraints
    and conversions as for simple assignment apply, taking the type of
    the scalar to be the unqualified version of its declared type.

(I presume that "optionally enclosed in braces" is not intended to permit
more than one level of braces.)

Both
    int n = 0;
and
    int n = {0};
are clearly valid, with identical semantics.  But this:
    int n = {{0}};
violates that requirement.  Since the requirement is under Semantics,
not Constraints, code that violates it has undefined behavior.  Starting
with C99, this is mentioned in Annex J.

My question: Why is this undefined behavior rather than a constraint
violation?

I suggest that moving that paragraph from Semantics to Constraints would
be an improvement.  Extra braces on a scalar initializer are easy to
detect, and requiring a diagnostic should not be a significant burden,
and would promote consistency.  (Alternatively, the standard could have
explicitly allowed arbitrarily nested braces.)

With the current requirements, a compiler could quietly generate code to
set n to 42, though I doubt that anyone would do that.

(I note that gcc issues a non-fatal warning with "-std=c17
-pedantic-errors", while clang treats it as a fatal error.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */