#3213 Error when using 2 function pointers in the same function in different scopes

[Johannes Pfister]

SDCC gives an error when 2 function pointers are defined in the same function in 2 different scopes.

When compiling the attached code does_not_work.c sdcc prints an error:

$ sdcc -mmcs51 -c ./does_not_work.c
./does_not_work.c:19: warning 112: function 'fp' implicit declaration
./does_not_work.c:19: error 101: too many parameters

AFAIK this code is completely valid C code, it also works with GCC and Clang with all enabled warnings (-Wall -Wextra -Wpedantic), so i think this is a bug in SDCC. I tested it with SDCC 3.8.0 and 4.1.0 (1) i tested this in GNU/Linux Debian 10 (buster) AMD64 and on GNU/Linux Debian 9 (stretch) armv7l with SDCC Version 4.0.7

The file does_work.c contains 5 version that do work and don't generate an error. There is no error when a data pointer instead of a function pointer is used and there is also no error when the function pointer was typedefed before. If one of both function pointer declarations and calls is removed, it also works. When the order is changed (see source code), there is also no error. There was also no error when the 2 function pointers, with different names, are declared in the same scope.

In the other hand, renaming one function pointer didn't help. Changing the function type to a version with 0 parameters also didn't help. SDCC also generates this error when using different function pointer types for each function pointer.

I only tested versions with a do { .... } while(0); loop, because this bug occurred when i was using this code inside macros. I didn't do any tests without this loop.

(1) This command was used for the test with SDCC Version 4.1.0, while the standard headers where in the same folder:

/path/to/sdcc/bin/sdcc -mmcs51 -c ./does_not_work.c -I.

[Johannes Pfister]

Tested a version without the do { .... } while(0); loop inside the if-block (the declaration and calls are still there), it does not generate an error.

Updated the does_work.c file.

[Erik Petrich]

I think this is related to bug [#3212]. In both bugs, something with how the blocks are nested is causing a symbol declared in an inner block to be removed from the symbol table prematurely.

[Benedikt Freisen]

I reckon that they are unrelated, because [#3212] appears to be caused by a broken sanity check.

[Erik Petrich]

Fixed in [r12555]