Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #379358 > unrolled thread

Re: MCC Compiler

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: MCC Compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-29 09:17 -0700

#379358 — Re: MCC Compiler

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> Or take this sequence:
>>>>
>>>>     int a = 0;
>>>>     int b = {0};
>>>>     int c = {{0}};
>>>>
>>>> The first is OK, so is the second (why?), but the third gives a
>>>> warning on gcc.  (Mcc passes the first two and fails the third.)
>>>
>>> The first and second are OK because the standard explicitly says
>>> so.  N1570 6.7.9p:
>>>
>>>     The initializer for a scalar shall be a single expression,
>>>     optionally enclosed in braces.
>>>
>>> As for the third, with "-std=c17 -pedantic-errors", gcc warns
>>> "braces around scalar initializer", while clang gives a fatal
>>> error "too many braces around scalar initializer".
>>>
>>> One could argue that "enclosed in braces" allows both {...} and
>>> {{...}}.  I don't think I'd make that argument myself.  But the
>>> requirement is in the Semantics section, not Constraints, so
>>> violating it is not a constraint violation.  IMHO it *should* have
>>> been a constraint.  I think clang is incorrect to reject it in
>>> conforming mode, [...]
>>
>> I don't see how you reach the conclusion about clang.  If you
>> think that in 6.7.9p11 the phrase "optionally enclosed in braces"
>> is meant to allow one pair of braces but not more than one, how
>> is it that you also think clang is not within its rights to
>> reject the declaration with two pairs of braces?  The two
>> inferred statements seem inconsistent with respect to each other.
>> Is it that you think that violating a syntax rule or violating a
>> constraint are the only things that give an implementation
>> license to refuse to translate a source file?  (Let me exclude
>> things like #error and #pragma from the discussion here.)  I have
>> to admit to being baffled.
>
> I did miss something.  This:
>
>     int c = {{0}};
>
> has undefined behavior (assuming that "optionally enclosed in braces"
> isn't meant to allow multiple braces).  A compiler may reject a program
> that has undefined behavior.  Or it may successfully translate it, or
> make demons fly out of your nose during execution.
>
> The question is why the standard made it UB rather than a constraint
> violation.  I can't think of any good reason.  Perhaps it was meant
> to cater to one or more implementations that happen to accept
> it;  personally, I wouldn't consider that to be a *good* reason.
> (Note that this case of UB is explicitly mentioned in Annex J,
> which might suggest that it was a deliberate choice.)
>
> It's possible that clang is choosing to reject it because it has
> undefined behavior (which raises questions about what happens if it's
> enclosed in `if (0) { ... }`, but I won't get into that).  My
> impression, however, is that clang is treating the requirement
> as if it were a constraint.
>
> Do you think that clang is allowed to reject `int c = {{0}};`?

I believe the intent of the C standard is that an implementation
may decline to accept a program containing this declaration and
still be conforming.

> If so, on what basis do you think so?

The standard requires implementations to accept any program that
is strictly conforming.  Part of the definition of being strictly
conforming is that the program use only those features specified
in the standard.  The standard does specify the case without any
braces, and also the case with exactly one pair of braces.  I
agree with your reading of the phrase "optionally enclosed in
braces", from which follows the conclusion that the standard does
not specify using two pairs of braces around the '0' in this
declaration.  Because the program is using a feature not
specified in the standard, the program is not strictly
conforming, and thus does not have to be accepted.

[toc] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web