[2274] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: #ifdef unix is wrong afaik

daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Feb 22 12:51:34 1997

To: "Richard Basch" <basch@lehman.com>
Cc: Sam Hartman <hartmans@MIT.EDU>, krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 22 Feb 1997 12:51:13 -0500
In-Reply-To: "Richard Basch"'s message of Sat, 22 Feb 1997 10:05:45 -0500

>>>>> "Richard" == Richard Basch <basch@lehman.com> writes:

    Richard> Actually, I re-read your message.  comerr (et_[ch].awk)
    Richard> should stay #ifdef unix.  Others may need changing, as
    Richard> necessary, but are likely to need to be revamped based on
    Richard> new OS, such as VMS, MVS/OpenEdition, etc.  I would
    Richard> prefer to have #ifdef unix, as those sections are
    Richard> generally Unix-centric.  In cases where it was unclear
    Richard> about other OS's such as MVS/OpenEdition and VMS, I
    Richard> preferred the !WINDOWS style.  Anyway, as I said, comerr
    Richard> should stay (or be made even more restrictive to the
    Richard> platforms where we wish to maintain the bad interface).
    Richard> The others are arguable but I fear a proliferation of if
    Richard> not X and not Y and not Z and not AA and not BB and not
    Richard> CC and not DD, where we are really trying to define
    Richard> Unix-centric behavior.  In fact, in places where #ifdef
    Richard> unix is wrong, it should not be #if not WINDOWS..., it
    Richard> should probably be made into a configure variable, with
    Richard> #ifdef HAVE_XYZ.  Until now, I did not know there were
    Richard> any Unix systems that did not define "unix"...

	Ok, it looks like we need to have some #define that is set on
all unix platforms.  #ifdef unix is wrong because there are examples
where it is not set, and because Ansi namespace rules tend to make it hard for an implementation to define it.  Does Gcc even define it with -ansi?

	I don't think forcing #ifdef unix to be defined is the right answer, because it may have unexpected consequences in third-party code.

    Richard> -- Richard Basch Sr. Developer/Analyst, DSO URL:
    Richard> http://web.mit.edu/basch/www/home.html Lehman Brothers,
    Richard> Inc.  Email: basch@lehman.com, basch@mit.edu 101 Hudson
    Richard> St., 38th Floor Fax: +1-201-524-5828 Jersey City, NJ
    Richard> 07302-3988 Voice: +1-201-524-5049


home help back first fref pref prev next nref lref last post