Groups | Search | Server Info | Login | Register


Groups > comp.std.c > #6585

int n = {{0}};

From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.std.c
Subject int n = {{0}};
Date 2023-10-26 19:57 -0700
Organization None to speak of
Message-ID <8734xwkc1c.fsf@nosuchdomain.example.com> (permalink)

Show all headers | View raw


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 */

Back to comp.std.c | Previous | NextNext in thread | Find similar


Thread

int n = {{0}}; Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-26 19:57 -0700
  Re: int n = {{0}}; Richard Damon <Richard@Damon-Family.org> - 2023-10-28 09:41 -0700
  Re: int n = {{0}}; Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-03 11:23 -0800
    Re: int n = {{0}}; Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-03 14:00 -0800
      Re: int n = {{0}}; Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-18 17:52 -0800

csiph-web