🚀 go-pugleaf

In article <4963@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>I'm still trying to get Unix to compile and run under an ANSI C compiler
>(gcc).  The latest wierd problem comes from the Fortran I/O library, where
>they define the number of significant digits in a float and then want
>to define a constant containing 1e(that number).  Under pcc, they used:
>
>#define LFD 6
>#define LHIGH 1.0e+LFD
>
>which expanded to
>
>1.0e+6
>
>which worked just fine.  This no longer works,....

The following works (I have tried it under gcc):

    #define cat_a(a,b) a ## b
    #define cat_b(a,b) cat_a(a,b)
    #define LHIGH cat_b(1.0e+,LFD)

This is because, as specified in the ANSI Standard, the LFD argument is
expanded before substitution into the definition of cat_b, so that a 
macro invocation of LHIGH becomes
    cat_a(1.0e+,6)
 
>Some of this [weirdness] may be due to gcc-1.24 bugs; I expect that:
>
>#define cat_a(a,b) a ## b
>#define cat_b(a,b) a ## b
>#define LHIGH cat_a(1.0e+,cat_b(LFD,))
>
>should work, but it produces:
>
>1.0e+cat_b(6 ,)  
>
>a wierd result, probably due to misimplementation of the overly complex
>ANSI C anti-self-calling rules.

Not so weird.  Given that the original version didn't work in gcc because
LFD immediately after the 1.0e+ was not recognized as a macro name, it is
consistent that cat_b should not be recognized as a macro name 
right after 1.0e+.

I confess, however, that I am a relative newcomer to the ANSI C standard,
and am not sure whether gcc's behavior is correct.

Paul Hilfinger
University of California at Berkeley
Hilfinger@Berkeley.EDU, hilfingr@ginger.Berkeley.EDU