[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC

From: Boehne, Robert
Subject: Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Date: Thu, 16 Jan 2003 09:29:08 -0600

Wouldn't replacing -DPIC with -D__PIC__ break a fundamental
assumption about ANSI compilers, that "__" means compiler-defined
and not in the userspace?

IMHO, I have yet to see an example of how it could be useful
to define "PIC" when it seems that the only way to make use of
it is to have it surround severely implementation-specific stuff
like inline assembler in which case the compiler _should_ be defining
"__PIC__" or some similar symbol.  The big problem with -DPIC is
that it is very easy to clash with some other macro.  It has only
three letters and so is very likely to clash with other macros.
Don't believe it?  A quick google search for "#define PIC" returned
this as the second result:
... stdio.h> #include <dos.h> /* interrupt related definitions */
#define CLK_TICK_INT
0x08 /* The clock tick interrupt */ #define PIC 0x20 /* Programmable
5k - Cached - Similar pages 

The 5th result showed another example of using "PIC" that would clash,
and the 11th contains this snippet in reference to inline sparc

#if (defined(__pic__) || defined(__PIC__)) && !defined(PIC) 
#define PIC 1 
The main problem with removing -DPIC is that there is a backward
compatability issue.  This issue would STILL exist if we renamed
PIC to a sensible name like LT__PIC__, and since compilers provide
this it doesn't seem necessary to keep it at all.

That's why my plan is to deprecate it for 1.5, and remove it in
a future release.


Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]