Hi, C is a bit lax with types -- if there is none given, it often assumes int, as in ''extern portb_isr'', which is (correctly) interpreted as ''extern int portb_isr;''.
>> For a SIGHANDLER that is defined in the SAME file, I have to forward >> declare it using: SIGHANDLER(portb_isr); ; extern portb_isr fails with: >> main.c:162: error 98: conflict with previous definition of 'portb_isr' >> for attribute 'type' >> from type 'int fixed' >> to type 'void function ( ) fixed' This is to be expected -- mismatches in the type of the declared object and the type of its implementation should at least be warned about. >> for a SIGHANDLER that is defined in ANOTHER file, I have to extern >> declare it using : extern i2c_slave_isr; extern >> SIGHANDLER(i2c_slave_isr); fails with: >> main.asm:247:Error [113] Symbol not previously defined (_i2c_slave_isr). >> main.asm:247:Error [113] Symbol not previously defined (_i2c_slave_isr). This is a bug in the PIC16 target of SDCC. As sdcc does not see a reference to the declared function, it drops it from the list of symbols to pull in from other modules. This is often useful, preventing the .asm files from EXTERN declaring each and every symbol that occurs in any of the (transitively) included header files. In this case, however, the assumption that unreferenced symbols are not required is plain wrong. I have no precise idea why 'extern foo' works -- probably (global) variables are treated different from functions; if I had time, I would look into this, but right now, we will have to remember that extern foo works or implement interrupt handlers in the main .c file. >> The errors are different! >> And the messages are even formatted differently :-) The first error message originates from SDCC (who can and does find a type mismatch as declaration and definition are visible at the same time/in the same file in this case), the second one is from the assembler (from the gputils project), who stumbles upon the lacking 'extern' declaration that sdcc/pic16 so conveniently decided not to emit. The error output is to be expected and perfectly fine for me. > Well, this is AFAIK, but the SIGHANDLER is a macro, not a C language > construct. Your 'forward declaration' probly does something, but not > what you want. If the PIC16 target code was right, the macro would work just fine. Best regards Raphael ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
