[comp.lang.c] #pragma macro

lerman@stpstn.UUCP (Ken Lerman) (06/27/90)

In article <1990Jun26.145937.27988@csrd.uiuc.edu> pommerel@sp14.csrd.uiuc.edu (Claude Pommerell) writes:
...[deleted]...
>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)
>I tried the following variants:
...[deleted]...
>
>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
...[deleted]...
>
>Does anybody know a variant that works and is conform with the ANSI C
>standard, but more elegant than the double preprocessing in variant 7 ?
>
>						Claude Pommerell
>						pommy@iis.ethz.ch
>					    or  pommerel@csrd.uiuc.edu


As far as I can determine, there is no way to do this in ANSI C.

Your solution, (7.) is not ANSI C, because it relies on the fact that
your compiler lets you run something through the preprocessor and get
at the output.

A -- There is no ANSI requirement that requires the ability to get at
the output from the cpp.

B -- Even if your compiler does have such output, there is no
requirement that the output after preprocessing is a legal C program.
In fact, I've seen at least two compilers where the output of cpp
(after including the vendor's include files) is acceptable to the
vendor's C compiler, but not to other (conforming) compilers.


Unfortunately, ANSI C (also K&R C) is very weak as far as macros are
concerned.  It would be nice to be able to define macros within
macros, ...

I've heard that m4 does a decent job as a macro processor (but haven't
used it).  If you want to be portable, I think you'll have to add
another tool to your chain.

Ken

henry@utzoo.uucp (Henry Spencer) (06/27/90)

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