[sdcc-devel] [ sdcc-Bugs-861242 ] missing deref on function pointer give faulty diagnostic

[SourceForge.net <no...@so...>]

Bugs item #861242, was opened at 2003-12-16 23:13
Message generated for change (Comment added) made by stsp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=861242&group_id=599

Category: C-Front End
Group: fixed
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stas Sergeev (stsp)
Assigned to: Erik Petrich (epetrich)
Summary: missing deref on function pointer give faulty diagnostic

Initial Comment:
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) 


----------------------------------------------------------------------

>Comment By: Stas Sergeev (stsp)
Date: 2004-02-06 22:22

Message:
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.

----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2004-02-04 09:50

Message:
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.


----------------------------------------------------------------------

Comment By: Stas Sergeev (stsp)
Date: 2003-12-19 19:40

Message:
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.

----------------------------------------------------------------------

Comment By: Mathias Neuhaus (mathiasn)
Date: 2003-12-19 12:32

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

----------------------------------------------------------------------

Comment By: Stas Sergeev (stsp)
Date: 2003-12-19 07:42

Message:
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.

----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2003-12-19 00:47

Message:
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.


----------------------------------------------------------------------

Comment By: Stas Sergeev (stsp)
Date: 2003-12-17 23:21

Message:
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?

----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2003-12-16 23:52

Message:
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=861242&group_id=599