Xref: utzoo comp.unix.questions:13284 comp.std.c:1154
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
Newsgroups: comp.unix.questions,comp.std.c
Subject: Re: How can I find out cc or cpp symbols?
Keywords: cpp, cc, macros
Message-ID: <7119@bsu-cs.bsu.edu>
Date: 5 May 89 17:37:20 GMT
References: <1954@trantor.harris-atd.com> <10084@smoke.BRL.MIL> <1339@ncr-sd.SanDiego.NCR.COM>
Reply-To: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 35

In article <1339@ncr-sd.SanDiego.NCR.COM> Greg.Noel@SanDiego.NCR.COM (Greg
Noel) writes:
>I've wondered why the ANSI committee didn't simply mandate that there be a
>header file, say <default.h>, that was implicitly #included, and that contained
>all the machine-specific, system-specific, and vendor-specific names.

It is a terrible idea to make any assumptions about vendor-specific symbols.
There are two reasons for this.

1.   You code should not be dependent on vendor-specific or OS-specific
symbols.  It ought to be dependent on specific attributes of different
environments.  For example:

     #ifdef unix
     ... code that assumes UNIX-like hard links ... /* BAD */
     #endif

     #ifdef NIX_LINKS
     ... code that assumes UNIX-like hard links ... /* BETTER */
     #endif

This way if you encounter a new system with some specific attributes,
you do not have to go searching through your code to figure out what to
change.

2.   Do not trust vendor-supplied symbols.  They are often wrong.  I
found out from Usenet that some Sun machines define "vax".  Worse,
System V machines define "unix".

The right way to deal with predefined symbols is to put all
dependencies on them in a separate header file, and *manually edit that
file* when installing software on a new system.
-- 
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP:    ...!{iuvax,pur-ee}!bsu-cs!dhesi