From: SourceForge.net <no...@so...> - 2003-12-19 04:42:30
|
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: None Status: Open Resolution: None Priority: 5 Submitted By: Stas Sergeev (stsp) Assigned to: Nobody/Anonymous (nobody) 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: 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 |