Xref: utzoo comp.lang.c:29925 comp.std.c:3310
Newsgroups: comp.lang.c,comp.std.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: #pragma macro
Message-ID: <1990Jun27.164537.6126@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1990Jun26.145937.27988@csrd.uiuc.edu>
Date: Wed, 27 Jun 90 16:45:37 GMT

In article <1990Jun26.145937.27988@csrd.uiuc.edu> pommerel@sp14.csrd.uiuc.edu (Claude Pommerell) writes:
>I am writing portable ANSI C code, but at some points I need to insert
>pragmas to use vectorization facilities of the compiler effectively.
>
>I would like to define a macro
>	#define _DIR_(p1,p2) #pragma thisdir(p1,p2)

There is inherently no fully portable way to do this.  Section 3.8.3.4 of
the Holy Writ sayeth (at the end of the discussion of macro substitution):
"The resulting completely macro-replaced preprocessing token sequence is
not processed as a preprocessing directive even if it resembles one."
Given that section 3.8 says "The preprocessing tokens within a preprocessing
directive are not subject to macro expansion unless otherwise stated", and
3.8.6 on #pragma does not otherwise state, there is no fix.  You can't get
a #pragma as the result of a macro, and you can't rely on macro substitution
inside #pragma.

The C preprocessor is not a general-purpose macro processor.

>7. I use the same idea as in variant 5, but run the preprocessing phase
>   twice, defining
>	   #define _DIR_(p1,p2) _HASH_ pragma thisdir(p1,p2)
>   and calling
>	   _DIR_(arg1,arg2)
>   and compiling
>	   cc -D_HASH_=# -I. -P FILE.c
>	   cc -c FILE.i
>   
>   At last, this seems to work.

This is fairly clever, although it relies on the ability to preprocess
twice, which is not guaranteed.  (ANSI C does not require the ability
to separate preprocessing from the rest of compilation at all.)
-- 
"Either NFS must be scrapped or NFS    | Henry Spencer at U of Toronto Zoology
must be changed."      -John Osterhout |  henry@zoo.toronto.edu   utzoo!henry