Hi Christoph, Thank you for finding a reference to the workaround of wrapping the system include with #ifndef S_SPLINT_S. Despite being inconvenient, I suppose that is the closest we have for a workaround.
I am Cc:ing the bug report for reference. Cheers, Giridhar On 08/12/05 12:27 +0100, Christoph Thielecke said ... > I find also a tip on: > http://www.perlfoundation.org/parrot/index.cgi?action=display_html;page_name=splint > > ==> > Recursive #define in a header file > My /usr/include/bits/confname.h includes both enums and defines for the same > tokens. It looks like this: > enum > { > _PC_LINK_MAX, > #define _PC_LINK_MAX _PC_LINK_MAX > _PC_MAX_CANON, > #define _PC_MAX_CANON _PC_MAX_CANON > etc, etc. I'm guessing they want to use an enum for compile-time > typechecking, but retain compatibility with code that uses #ifdef to > determine its presence, or something. Anyway, splint barfs on this with > an "internal error": > /usr/include/bits/confname.h:31:27: *** Internal Bug at cscannerHelp.c:2422: > Unexpanded macro not function or constant: int _PC_MAX_CANON [errno: 25] > *** Please report bug to [EMAIL PROTECTED] *** > (attempting to continue, results may be incorrect) > /usr/include/bits/confname.h:32:1: Parse Error: Non-function declaration: > _PC_MAX_CANON : int. (For help on parse errors, see splint -help > parseerrors.) > *** Cannot continue. > > > The nice thing about this error, of course, is that it waits until after all > sourcefile processing to emit this error. Which means you think everything's > running great, and yet you're denied your nifty summary at the end. > For now, I've wrapped my system include with #ifndef S_SPLINT_S. But its > another argument in favor of keeping splint as far away from system headers > as possible... > <=== -- Y Giridhar Appaji Nag | http://appaji.net/
signature.asc
Description: Digital signature
