Hi.
The following (attached) perfectly valid C code
doesn't compile under sdcc, producing a meaningless
error message instead.
Is passing a pointer to function with parameters
as a function parameter supported? If not, then at
least the error message must be somehow fixed I think.
---
char tst1(char a)
{
return a+1;
}
char tst(char (*f)(char))
{
return f(2);
}
int main()
{
return tst(tst1);
}
---
$ sdcc func.c
func.c:8: error: too many parameters
func.c:8: error: code not generated for 'tst' due to
previous errors
-:0: error: code not generated for 'main' due to
previous errors
$ sdcc -v
SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.3.6 (Dec 9 2003) (UNIX)
test case
Logged In: YES
user_id=635249
This is a known deviation from the C standard. You'll need
to explicitly dereference the call; i.e.:
return (*f)(2);
see:
http://sdcc.sourceforge.net/doc/sdccman.html/node64.html
While in principle I would like to eliminiate all of these
language deviations, this particular one is at the top of my
list since it causes problems for the most people.
Logged In: YES
user_id=501371
OK, thanks for the hint. (*f)() is fine with me since I
can use a simple #defines to make it f(). Just wondering,
if it is a known and documented issue, why the error
message is so meaningless, that it looks like the bug was
hited? :)
Anyway, I tried that. Unfortunately that works unreliably.
Sometimes it compiles, sometimes sdcc just crashes.
I've opened the bug #861896 for that.
Btw, a slightly unrelated question, but hopefully not a
complete offtopic: why the "at" keyword is silently ignored
when used inside a struct/union?
The definition like
union {
xdata at 10 unsigned char a;
unsigned char b;
};
is probably invalid, but sdcc accepts it simply ignoring
the storage class. Is it a bug or I missed something in the
docs again?
Logged In: YES
user_id=635249
The missing dereference seems to cause sdcc to lose track of
the formal parameters of the called function and so assumes
there are none; thus any passed parameters are "too many". I
haven't found the root cause yet, though.
Storage classes and 'at' specifiers in struct/unions now
generate a reasonable diagnostic. See the ChangeLog for details.
Logged In: YES
user_id=501371
Hi.
> generate a reasonable diagnostic. See the ChangeLog for
> details.
Yes, very nice diagnostic now, thanks.
But you probably have some newer gcc there if it compiles
for you - for me it produces an error for some reasons.
The attached patch fixes that compilation glitch.
Fix compilation
Logged In: YES
user_id=850360
Hi Stas,
> The definition like
> union {
> xdata at 10 unsigned char a;
> unsigned char b;
> };
> is probably invalid, but sdcc accepts it simply ignoring
> the storage class.
as you write that's a definition of a type, not the declaration
of a variable thereof.
You can specify the storage class only for declarations.
Maybe SDCC should generate some warning here.
bis die Tage...
Mathias
Logged In: YES
user_id=501371
Hi.
> You can specify the storage class only for declarations.
Of course, and I was wondering why sdcc silently accepts
an incorrect code (well, incorrect type declaration if you
like). Silently accepting the wrong code looks like a bug
to me.
> Maybe SDCC should generate some warning here.
Well, you are a bit out of date with that:)
Erik is working *amazingly* quickly, and if you update
from CVS, the fact is that sdcc now produces a nice error
message for that case, instead of generating a wrong code.
Logged In: YES
user_id=635249
The compiler now checks that you have a function or pointer
to function before checking the parameters. So now we get a
more appropriate "called object is not a function" rather
than the cryptic "too many parameters".
Even better, the compiler now supports the standard ANSI
calling semantics ; an explicit dereference of a function
pointer is no longer required (but still allowed, since ANSI
allows this too).
Fixed with src/SDCCicode.c 1.187 and src/SDCCast.c 1.218.
Logged In: YES
user_id=501371
Hi Erik,
Thanks but your fix doesn't work properly for me.
New test-case is attached. Now it is simply a SIGSEGV,
no more ICE.
Logged In: YES
user_id=501371
Sorry, now I see you already fixed also this.
The problem is that the CVS build is broken right now.
The patch is attached.
The *real* problem is that due to some flaws in an sdcc
build system, if some file doesn't compile, "make" just
goes on, instead of to abort. So initially I haven't even
noticed that the source doesn't compile, and was thinking
I am up-to-date, but I wasn't. Why this happens? Is it
possible to do something so that the error in sdcc source
file to stop the build process?