Groups | Search | Server Info | Login | Register
| Path | csiph.com!1.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx14.iad.POSTED!not-for-mail |
|---|---|
| MIME-Version | 1.0 |
| User-Agent | Mozilla Thunderbird |
| Subject | Re: int n = {{0}}; |
| Content-Language | en-US |
| Newsgroups | comp.std.c |
| References | <8734xwkc1c.fsf@nosuchdomain.example.com> |
| From | Richard Damon <Richard@Damon-Family.org> |
| In-Reply-To | <8734xwkc1c.fsf@nosuchdomain.example.com> |
| Content-Type | text/plain; charset=UTF-8; format=flowed |
| Content-Transfer-Encoding | 7bit |
| Lines | 53 |
| Message-ID | <kRa%M.330599$w4ec.60402@fx14.iad> (permalink) |
| X-Complaints-To | abuse@easynews.com |
| Organization | Forte - www.forteinc.com |
| X-Complaints-Info | Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly. |
| Date | Sat, 28 Oct 2023 09:41:51 -0700 |
| X-Received-Bytes | 3012 |
| Xref | csiph.com comp.std.c:6586 |
Show key headers only | 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
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