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

Groups > comp.lang.c > #359634

Re: MCC Compiler

Show all headers | View raw

bart <bc@freeuk.com> writes:
> On 25/10/2023 21:42, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> One thing that makes it hard IMO is that a lot of C isn't very
>>> rigorously defined. You can easily have a program that either passes,
>>> fails, or passes with warnings, depending on compiler and options.
>> Any behavior of a compiler invoked in non-conforming mode (including
>> most C compilers in their default) is irrelevant to the question of how
>> rigorously C is defined.
>> 
>>> 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, though a warning is
>> certainly appropriate.
>> So yes, in this specific case the standard is a bit vague about the
>> validity of `int c = {{0}};`.
>> 
>>> I know that when an array/struct is initialised, extra braces are not
>>> allowed, but fewer braces are OK:
>>>
>>>      int a[2][3] = {1,2,3,4,5,6};
>>>      int b[2][3] = {{1,2,3}, {4,5,6}};
>>>
>>> Here, gcc passes both, even though the shape of the data doesn't match
>>> the type of 'a'.
>>>
>>> There is a some algorithm involved to figure out which braces can be
>>> legally left out. Mcc doesn't use it; it requires braces to exactly
>>> match the type's data structure, so 'a' fails, and 'b' parses.
>> Other than {{scalar}}, the rules for braces in initializers are
>> complicated but unambiguous.  Allowing nested braces to be omitted lets
>> {0} be a valid initializer for any object type, which can be very
>> convenient.  (C23 allows {}.)
>
> It also allows this:
>
>     int a[2][3] = {1,2,4,5,6};
>
> Element '3' has been left out by mistake. Now all elements are out of
> step, and the last has value 0 instead of 6.
>
> I couldn't believe it when I discovered this.

C allows something you don't like.  You're shocked.  Lather, rinse, repeat.

It deliberately allows omitting all but the outer braces, so that a
multi-dimensional array can be initialized with a single brace-enclosed
list of values.  Any trailing values (struct members or array elements)
that are not specified are initialized to zero.

It also allows:

    int a[2][3] = {42};

which sets a[0][0] to 42 and all other elements to 0, and the universal
initializer:

    some_type obj = {0};

falls out of the rules (C++ and C23 allow {}).

If you want to avoid that kind of error, don't omit the inner braces.

Large initializers are likely to be automatically generated, so barring
a bug in the code generator this problem is unlikely to occur.

[...]

Please keep in mind that nobody here is either responsible for the
current rules or in any position to change them.

-- 
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.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: MCC Compiler Bart <bc@freeuk.com> - 2023-10-25 16:29 +0100
  Re: MCC Compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-25 20:52 +0100
    Re: MCC Compiler bart <bc@freeuk.com> - 2023-10-25 21:46 +0100
  Re: MCC Compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-25 13:42 -0700
    Re: MCC Compiler bart <bc@freeuk.com> - 2023-10-26 01:30 +0100
      Re: MCC Compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-25 18:17 -0700
        Re: MCC Compiler bart <bc@freeuk.com> - 2023-10-26 13:10 +0100
          Re: MCC Compiler David Brown <david.brown@hesbynett.no> - 2023-10-26 15:50 +0200
        Re: MCC Compiler Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-26 20:59 +0000
    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

csiph-web