make
gcc -O -c -o a.o a.c
In file included from j.h:39,
from a.c:14:
je.h:191: error: 'nan' redeclared as different kind of symbol
/usr/include/math.h:177: error: previous declaration of 'nan' was here
je.h declares nan as extern D where type is typedef double D
math.h declares nan as:
extern double nan _PARAMS((const char *));
nan is only used in a few places in the code:
find . -type f -print0 | xargs -0 -e grep -nH -e nan
./i.c:77: MC(&nan,XNAN,(size_t)sizeof(D));
./j.c:31:D nan;
./je.h:191:extern D nan;
./je.h-:193:extern D nan;
./wn.c:20: if('-'==*s&&3>n){x=1==n?inf:(c=*(1+s),c=='-')?-inf:c=='.'?
nan:0; if(x){*v=x; R 1;}}
So I'm wondering what technique would be best to rename all the nan
calls in the code to something else to avoid conflicts. Perhaps some
sort of #define is in order.
> Compilation error:
>
> make
> gcc -O -c -o a.o a.c
> In file included from j.h:39,
> from a.c:14:
> je.h:191: error: 'nan' redeclared as different kind of symbol
> /usr/include/math.h:177: error: previous declaration of 'nan' was here
>
> je.h declares nan as extern D where type is typedef double D
>
> math.h declares nan as:
> extern double nan _PARAMS((const char *));
>
> nan is only used in a few places in the code:
>
> find . -type f -print0 | xargs -0 -e grep -nH -e nan
> ./i.c:77: MC(&nan,XNAN,(size_t)sizeof(D));
> ./j.c:31:D nan;
> ./je.h:191:extern D nan;
> ./je.h-:193:extern D nan;
> ./wn.c:20: if('-'==*s&&3>n){x=1==n?inf:(c=*(1+s),c=='-')?-inf:c=='.'?
> nan:0; if(x){*v=x; R 1;}}
You may want to remove the two useless spaces in that line that are
helping readability at the expense of wasted bytes. Also:
if(x)R *v=x,1;
might work to remove one set of those pesky {}s. :-)
Seriously, you may want to reconsider your coding guidelines.
> So I'm wondering what technique would be best to rename all the nan
> calls in the code to something else to avoid conflicts. Perhaps some
> sort of #define is in order.
I'd rename your nan (since it occurs so infrequently) rather the
trying to move the standard one off to one side.
--
Ben.
:)
This is not my code. It is an early open source version of the J
programming language:
ftp://ftp.gaertner.de/pub/j/j-v7-src.tgz
>
> > So I'm wondering what technique would be best to rename all the nan
> > calls in the code to something else to avoid conflicts. Perhaps some
> > sort of #define is in order.
>
> I'd rename your nan (since it occurs so infrequently) rather the
> trying to move the standard one off to one side.
Ok. thanks. I will do that.
It's not supposed to do that; <math.h> is not allowed to
declare `nan' at all. The gcc compiler is famous/notorious
for compiling "C with extras" in its default mode of operation;
try running it in a conforming mode with
gcc -ansi -pedantic ...
or
gcc -std=whatever -pedantic ...
... and see if that suppresses the gratuitous `nan' declaration.
--
Eric Sosman
eso...@ieee-dot-org.invalid
> metap...@gmail.com wrote:
>> Compilation error:
>>
>> make
>> gcc -O -c -o a.o a.c
>> In file included from j.h:39,
>> from a.c:14:
>> je.h:191: error: 'nan' redeclared as different kind of symbol
>> /usr/include/math.h:177: error: previous declaration of 'nan' was here
>>
>> je.h declares nan as extern D where type is typedef double D
>>
>> math.h declares nan as:
>> extern double nan _PARAMS((const char *));
>> [...]
>
> It's not supposed to do that; <math.h> is not allowed to
> declare `nan' at all.
Eh? double nan(const char *); is in C99. I can't see how it could
avoid declaring it but, since I have not know you to be wrong, I await
being corrected!
--
Ben.
Ben, I really wish you'd stop arguing with me when
I have egg all over my face. Just because I'm wrong,
R-O-N-G wrong, is no excuse for you to be right.
(In other words, the reports of my infallibility have
been greatly exaggerated. Thanks for the correction.)