fastspin C compiler
David Betz
Posts: 14,516
I just started trying to compile my embedded BASIC interpreter for the P2 and ran into this error when compiling one of the source files:
The line in question is the reference to GetLineHandler in the System structure definition below. VMVALUE is just an integer typedef. Am I using a feature that is not yet supported by the fastspin C compiler?
db_system.h(23) error: syntax error, unexpected identifier `GetLineHandler'
The line in question is the reference to GetLineHandler in the System structure definition below. VMVALUE is just an integer typedef. Am I using a feature that is not yet supported by the fastspin C compiler?
/* line input handler */ typedef int GetLineHandler(void *cookie, char *buf, int len, VMVALUE *pLineNumber); /* system context */ typedef struct { jmp_buf errorTarget; /* error target */ GetLineHandler *getLine; /* function to get a line of input */ void *getLineCookie; /* cookie for the getLine function */ int lineNumber; /* current line number */ uint8_t *freeSpace; /* base of free space */ uint8_t *freeMark; /* top of permanently allocated storage */ uint8_t *freeNext; /* next free space available */ uint8_t *freeTop; /* top of free space */ char lineBuf[MAXLINE]; /* current input line */ char *linePtr; /* pointer to the current character */ } System;In case you want to try this yourself I've attached the sources. My first attempt at compiling it was using the command:
fastspin -2 -D PROPELLER_GCC *.cThat would eventually generate errors because it is including duplicates of the OS interface functions but I thought it was an easy way to start.
zip
44K
Comments
Thanks for the bug report!
Edit: Actually, the more I think of it this *is* one of the big advantages of C++. It's a pain having to split a declaration into two pieces and type the structure tag three times. C++ was certainly an improvement here! I could have left out the typedef line entirely.
NextToken(ParseContext *C) and NextToken(System *sys), I think.
I looked at the assembly, and the compiler puts literal strings in a section called "rdata". So it appears that this is what's causing the warning.
Yes, the C standard does say that string literals are "const", and gcc used to warn about this but i guess so many programs pass literal strings to "char *" that they disabled that warning (even if -Wall is given you still have to explicitly give -Wwrite-strings to get it). I should probably take the same route, or at least provide a compiler option to disable those warnings.
Note that even without the warning strings really are consts, e.g. the program below will segfault on Linux when compiled with gcc or clang:
https://stackoverflow.com/questions/2245664/what-is-the-type-of-string-literals-in-c-and-c
Yes, looks like automatic casting of arrays to pointers is broken. I'll look into it. Thanks for the bug report!
Huh. I guess my memory is going as I'm getting older . Well, that makes things easier, I can just get rid of the warning completely. Thanks!
For now feel free to comment out that WARNING line in frontends/basiclang.c (another thing I have to get around to, the type checking code is shared between BASIC and C and should go in its own file).
Thanks,
Eric