Groups | Search | Server Info | Login | Register

Groups > comp.std.c > #6586

Re: int n = {{0}};

Show all headers | View raw

On 10/26/23 7:57 PM, Keith Thompson wrote:
> 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.)
> 

I wonder a bit if this is bowing to conflicting existing 
implementations. So were giving a fatal error for the extra braces, 
while some specifically permitted them, and have a measurable code base 
that uses that permision.

Back to comp.std.c | Previous | Next — Previous in thread | Next 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