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

Groups > comp.lang.c > #354182 > 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 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

#354182 — Re: MCC Compiler

On 16/10/2023 03:26, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 29/09/2023 06:10, Tim Rentsch wrote:

>>> and aren't faithful to
>>> the C language (and it isn't clear whether you don't know that or
>>> if you just don't care).
>>
>> In which ways?
> 
> No one knows but you, and it's not even clear if you know.
> Ironically, if you were to go through and make up a list of
> differences between what your compiler accepts and what the
> C standard requires, and present that list here, that WOULD
> be topical, especially if there were reasons related to how
> easy or hard some aspects of C are to compile.  For reasons
> beyond understanding you leave out exactly the pieces of
> information that would make it relevant in comp.lang.c.  I'm
> at a loss to understand why you do that.

Rather than list all the shortcoming of my compiler, easier to say that 
the front-end needs a rewrite.

The overhaul I did in September this year was in replacing the backend, 
which addressed some urgent code-gen issues and hopefully made it less 
buggy.

At the moment I'm not looking at working on the front-end, and the 
project remains a personal one used for C code I write, the C I 
generate, and whatever external C I come across that is within its 
capabilities. That includes most stuff posted here.

 > if there were reasons related to how easy or hard some aspects of C 
are to compile

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.

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

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.

Here's one more:

     static int a;
     extern int a;
     static int a;

The above is passed by gcc, but this fails (Mcc just passes both);

     extern int a;
     static int a;
     extern int a;

There is tons of this stuff. Somehow I don't think that rewrite is going 
to happen. To write a compiler you need have clear rules about what 
constitutes a valid program.

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

[toc] | [next] | [standalone]

#356276

Bart <bc@freeuk.com> writes:

> ... To write a compiler you need have clear rules about what constitutes
> a valid program.

You don't think the rules exist, or you don't consider them to be clear?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#356967

On 25/10/2023 20:52, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> ... To write a compiler you need have clear rules about what constitutes
>> a valid program.
> 
> You don't think the rules exist, or you don't consider them to be clear?
> 

The rules probably do their best trying to formalise a messy, untidy 
language due to diverse implementations.

But no I don't consider them to be clear.

[toc] | [prev] | [next] | [standalone]

#356938

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

[toc] | [prev] | [next] | [standalone]

#359057

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.

(I also wasn't that keen on missing elements being set to zero, when 
when the braces are correct, since you can have a similar problem when 
elements can be left out by mistake, or a comma omitted: {1,2,34,5,6}. 
I'd have prefered a syntax like a trailing ... here to denote padding 
with zeros.)







> 
> [...]
> 
>> C is just too lax amd too open-ended, sorry.
> 
> I don't think it's nearly as lax as you say it is.

Perhaps you haven't tried to implement it!

[toc] | [prev] | [next] | [standalone]

#359634

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

[toc] | [prev] | [standalone]

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

csiph-web