Re: lynx-dev Development annoyance when building with ncurses

[dickey]

> 
> While inserting various bits of debug code in GridText.c, I found 
> that when building with ncurses-4.2-latest, preprocessor directives 
> like: 
>  
>  #if TRUE  /* [or FALSE] */ 
>  ... 
>  #endif 
I hadn't noticed that (but it's been in its present form since before 4.2
came out).  will check.
  
> are not recognized, and result in a gcc "parse error", though they 
> work fine when compiling with slang. 
>  
> Yes, I know I can use "#if 1" or "#if 0", but using TRUE/FALSE symbols 
> make it easier to spot/grep the temp code when it's time to remove it, 
> etc. 
>  
> Seems silly that ncurses would (re)define TRUE/FALSE in such a way as 
> to make such statements break, but perhaps there is a good reason for 
> it. 
ncurses defines TRUE/FALSE (it's specified in the X/Open description of curses,
which also says that curses.h declares the 'bool' type - which in turn is
also declared in c++, which makes life a little complicated)
  
> Tom ...? 
>  
> /kim 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey