#1441 typedef defined inside fun. and used outside causes SIGSEGV


void f(void)
typedef int TInt;
__code const TInt Int = 0;

Compiles with error:
Caught signal 11: SIGSEGV

Should report same error like when TInt isn't defined:
Source9.c:5: syntax error: token -> 'Int' ; column 21

SDCC version:
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.8.0 #5117 (Mar 23 2008) (MINGW32)
command line:
sdcc.exe -c --debug --use-stdout -V --std-sdcc99 -I... Source7.c

WXP HE PL SP2, AMD Athlon XP 1700+


  • RvS

    RvS - 2008-04-29

    Logged In: YES
    Originator: NO

    I looked into this problem.
    When the code of function f() is parsed. The Symbol TInt is added to SymbolTab and later on also to TypedefTab.
    In createFunction() in SDCCast.c a cleanupBlock is done. and thus the Typedef is removed.
    When parsing the __code const TInt Int=0; line in check_type in SDCC.lex TInt is found in the symbol table and identified as a typedef.
    The parser then continues until SDCC.y line 711 where it looks up the symbol in the TypedefTab, but it obviously doesn't find it.
    Iam not sure what the right solution here is.
    One is that the symbol should be removed from the SymbolTab for the same reason as it is removed from the TypedefTab.
    Another could be that for other reasons the SymbolTab cannot be cleaned. In that case the code in SDCC.lex should be robust against a NULL return from findSym(TypedefTab, NULL, $1) in line 711

  • Maarten Brock

    Maarten Brock - 2008-05-15

    Logged In: YES
    Originator: NO

    I'm not sure if SybolTab can be cleaned. I've found another way to solve this with an extra check if the symbol is really in the TypedefTab before returning TYPE_NAME. Also made SDCC.y safe for NULL-pointers. It's in SDCC 2.8.1 #5156.

  • Maarten Brock

    Maarten Brock - 2008-05-15
    • milestone: --> fixed
    • assigned_to: nobody --> maartenbrock
    • status: open --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks