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

Groups > comp.lang.c > #366862 > 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-26 09:34 -0700
    Re: MCC Compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-26 12:03 -0700

#366862 — Re: MCC Compiler

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.

[toc] | [next] | [standalone]

#367779

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}};`?

If so, on what basis do you think so?

(To be clear, I'm asking about a basis for rejecting it specifically
because of the extra braces.)

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

[toc] | [prev] | [standalone]

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

csiph-web