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

Groups > comp.lang.c > #356938

Re: MCC Compiler

Show all headers | View raw

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 {}.)

[...]

> C is just too lax amd too open-ended, sorry.

I don't think it's nearly as lax as you say it is.

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

csiph-web