Re: [RFA] gdb.base/shr1.c: Avoid preprocessor conflict on IRIX

[David Anderson <davea@quasar.engr.sgi.com>]

Kevin Buettner <kevinb@redhat.com> writes:
>Another Irix change.  I don't really like this change; I played around
>with compiler options in an attempt to avoid changing the source code,
>but the only one that I came up with which might work is -Usgi.  But
>that's dangerous because there may be a system header which depends upon
>``sgi''.


No IRIX header (as distinct from
user-written headers) should be standards-correct and 
depend on 'sgi' as it's clearly in the user namespace.
Unfortunately a check thru some IRIX headers finds a few
such broken headers :-(
These are not things most apps would #include 
as they go into areas not covered by existing standards.
Otherwise someone would have cleaned them up.

./netns/idp_var.h:#ifdef sgi
./netns/ns_pcb.h:#ifdef sgi
./netns/ns.h:#ifdef sgi
./netns/spp_var.h:#ifdef sgi
./netns/ns_error.h:#ifdef sgi
./netns/spp_timer.h:#ifdef sgi
./netns/ns_if.h:#ifdef sgi
./resolv.h:#if ((!defined(BSD)) || (BSD < 199306)) && !defined(sgi)
./arpa/nameser.h

In nearly all of these 'sgi' has no effect unless 'KERNEL'
is also #defined.
In the other ones the effect on gdb test cases should also be nil.

Normally 'sgi' is defined because it was defined before the 
C Standard rules came into effect in 1989.

-Usgi seems perfectly sensible to me on IRIX, for compiling
most test code (as long as the test code is not *looking* for -Dsgi :-)
though given what I just discovered your caution is sensible.
But still I think -Usgi would be fine (untested assertion
on my part).

Sign me a little embarrassed: I would not have thought we
still had any such cruft laying around. 
David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea