Hi.
The following example (attached) is rejected by
sdcc. But I beleive that it is the perfectly valid
code, and gcc takes it without a warning.
The severity of this problem is minor, but I just
wanted you to be aware of that.
---
extern unsigned char t[3];
unsigned char t[] = { 1, };
unsigned char main()
{
return 0;
}
---
$ sdcc ade.c
ade.c:2: error 91: extern definition for 't' mismatches
with declaration.
ade.c:1: error 177: previously defined here
ade.c:5: error 103: code not generated for 'main' due
to previous errors
And can someone please finally remove that silly
"code not generated" error messages that really hurt
some users? The patch is still here:
http://sourceforge.net/tracker/index.php?func=detail&aid=887171&group_id=599&atid=300599
together with an explanation.
a test-case
Logged In: YES
user_id=1115835
The problem here is rather the incomplete initializer "{ 1, }" than the extern definition. According to ISO 9899:TC2 (draft from May 6, 2005), 6.7.8 incomplete initializers are allowed, but probably unsupported by SDCC as of now.
Using the semantically equivalent "{ 1, 0, 0 }" form works fine. This might even be considered a feature, forcing the programmer to explicitly initialize all (or none) of the array members...
Logged In: YES
user_id=888171
SDCC supports incomplete initializers, but this setup has
it's information spread out a bit too wide.
extern unsigned char t[3];
unsigned char t[] = { 1, 0, 0 }; //ok
extern unsigned char t[3];
unsigned char t[3] = { 1, }; //ok with or without ,
extern unsigned char t[];
unsigned char t[3] = { 1 }; //ok
extern unsigned char t[3];
unsigned char t[] = { 1, }; //how big is this?
The extern declaration will only be checked afterwards
against the definition. It does not convey information
into the definition, but maybe it should.
Fixed in SDCC 2.9.4 #5561.