[LCC] Array of filled structures - compilation error

[Maciej Labanowicz]

Hello,

Following code can not be compiled by LCC:

--[beg:main.c]---------------------------
#include <stdio.h>
#include <stdlib.h>

static struct
{
char const * name;
unsigned int value;
} const VALUES [] =
{
{"zero", 0},
{"one", 1},
{"two", 2},
{"milion", 1000000}
};

int main(void)
{
unsigned int i = 0;
while (i < (sizeof(VALUES) / sizeof(*VALUES)))
{
printf("[%u] = {\"%s\", %u}\n", i, VALUES[i].name,
VALUES[i].value);
++i;
}
return EXIT_SUCCESS;
}

--[eof:main.c]---------------------------

> C:\lcc\bin\lcc.exe -v
Logiciels/Informatique lcc-win32 version 3.8. Compilation date: Nov 17
2011 11:01:32

> C:\lcc\bin\lcc.exe -O -c main.c
Error main.c: 9 missing semicolon after structure declaration
1 error, 0 warnings

NOTE:
> gcc -W -Wall -ansi -pedantic main.c
a.exe generated without any warning

Regards

--
Maciek

[jacob navia]

This is an error in lcc-win. If you eliminate the "const" keyword
the bug disappears.

This has been fixed, I will upload the fix tomorrow.

Why this bug?

If you forget to put a semicolon after a structure, sometimes the
problem is detected dozens of lines further out, specially if you happen
to start a function:

struct foo {
int a,b;
} // missing semicolon

int main(void) {
/* etc blah blah */
}

So, I tested explicitely for a seicolon and other followups
characters that could possibly appear after a structure
definition:

In decl.c:

if (t != ';' && t != ID && t != '*' ) {
// "missing semicolon after structure declaration\n"
error(StrTab[474]);
}
"ID" means any identifier. So, I thought that after a structure
declaration you can write a semicolon, an identifier or a "*"
to define a pointer to that type of struct.

You see the bug?

I have now changed that to:
if (t != ';' && t != ID && t != '*'
&& t != CONST && t != VOLATILE ) {
}

Are there any other followup that I am missing?

I hope not.

Thanks for your bug report.

jacob

[Ben Bacarisse]

jacob navia <ja...@spamsink.net> writes:
<snip>

> In decl.c:
>
> if (t != ';' && t != ID && t != '*' ) {
> // "missing semicolon after structure declaration\n"
> error(StrTab[474]);
> }
> "ID" means any identifier. So, I thought that after a structure
> declaration you can write a semicolon, an identifier or a "*"
> to define a pointer to that type of struct.
>
> You see the bug?
>
> I have now changed that to:
> if (t != ';' && t != ID && t != '*'
> && t != CONST && t != VOLATILE ) {
> }
>
> Are there any other followup that I am missing?

Yes, '(' and 'restrict'.

<snip>
--
Ben.

[jacob navia]

Le 16/01/12 17:24, Ben Bacarisse a écrit :

> jacob navia<ja...@spamsink.net> writes:
> <snip>
>> In decl.c:
>>

>> if (t != ';'&& t != ID&& t != '*' ) {

>> // "missing semicolon after structure declaration\n"
>> error(StrTab[474]);
>> }
>> "ID" means any identifier. So, I thought that after a structure
>> declaration you can write a semicolon, an identifier or a "*"
>> to define a pointer to that type of struct.
>>
>> You see the bug?
>>
>> I have now changed that to:

>> if (t != ';'&& t != ID&& t != '*'
>> && t != CONST&& t != VOLATILE ) {

>> }
>>
>> Are there any other followup that I am missing?
>
> Yes, '(' and 'restrict'.
>
> <snip>

restrict is not allowed as far as gcc (with -std=c99)
is concerned. And in any case should be "* restrict"
isn't it?

What the ('( is concerned you mean:

struct foo { int a;} (*fn)(void);

That one?

[Ben Bacarisse]

Yes, but it depends how you want to deal with the error. The syntax
permits it, so there is some argument for accepting it and issuing a
specific error later when checking the parse tree. You can then report
that what is restricted is not a pointer. If you leave it as a syntax
error, it is likely to be more confusing.

> What the ('( is concerned you mean:
>
> struct foo { int a;} (*fn)(void);
>
> That one?

Yes, and similar for pointers to arrays: struct foo { int a; } (*p)[3];

--
Ben.

[jacob navia]

Le 16/01/12 21:12, Ben Bacarisse a écrit :

>> What the ('( is concerned you mean:
>>
>> struct foo { int a;} (*fn)(void);
>>
>> That one?
>
> Yes, and similar for pointers to arrays: struct foo { int a; } (*p)[3];
>

OK. Thanks for this Ben, it spares me a future bug report!

The problem with this kind of error reporting is that you can
screw things nicely... Yes, the errors are more specific and
they help more the user but figuring out exactly all the possible
followups is a very difficult task.

[Jun Woong]

Any of the FIRST set of the declaration-specifier and of declarator
need to be considered. For example,

struct tag {
...
} static x;

is uncommon and, IIRC, deprecated by the Standard, but still valid.
It is free to diagnose this but a conforming compiler should accept
it.


--
Jun, Woong (woong.jun at gmail.com)

[jacob navia]

Le 18/01/12 02:38, Woong Jun a écrit :

>
> Any of the FIRST set of the declaration-specifier and of declarator
> need to be considered. For example,
>
> struct tag {
> ...
> } static x;
>
> is uncommon and, IIRC, deprecated by the Standard, but still valid.
> It is free to diagnose this but a conforming compiler should accept
> it.

WOW, I did not know that a "static" was allowed there. I mean that comes
because the arbitrary order in declarations like

long static s;

Well, I think I will just give up. This becomes incredibly messy.

Too bad that a nice, helpful compiler is so terribly complicated
to build because of that weird rules.