The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com (Steve Johnson)
Subject: [TUHS] Mac OS X is Unix
Date: Tue, 03 Jan 2017 16:13:54 -0800	[thread overview]
Message-ID: <74a6eaa2dc832b400b58a56a4fa1f4bc00398314@webmail.yaccman.com> (raw)
In-Reply-To: <201701032019.v03KJ8oq028944@tahoe.cs.Dartmouth.EDU>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

Following on Doug's comment, when I wrote the portable C compiler my
vision was to separate out the machine independent parts of the
compiler (e.g, the lexer and parser) from the machine dependent parts
(those parts involving stack frames, instructions, etc.).  Then to
port the compiler, you could leave the machine independent code alone
(much of which was rather hairy, involving symbol tables,
optimizations, etc.) and simply describe the instructions and calling
sequence in the machine dependent files.  The preprocessor was
actually pretty important in carrying this out, because there were a
fair number of machine characteristics ( such as byte order and word
size) that were handled identically across different architectures but
the actual values were different.  These were handled by defining
some preprocessor macros.

Several years later, I had moved to development and was responsible
for shipping a variety of different compilers, most resting on the PCC
base.  At one point, I was appalled to see that somebody had put some
code into one of the machine-independent files that was bracketed with
"# ifdef VAX".  There followed a most difficult conversation with the
perpetrator who kept insisting that, after all, the code WAS the same
on all machines...

----- Original Message -----
From: "Doug McIlroy" <doug@cs.dartmouth.edu>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Tue, 03 Jan 2017 15:19:08 -0500
Subject:Re: [TUHS] Mac OS X is Unix

 > keeping the code I work on portable between Linux and the Mac
requires
 > more than a bit of ‘ifdef’ hell.

 Curmudgeonly comment: I bristle at the coupling of "ifdef" and
"portable".
 Ifdefs that adjust code for different systems are prima facie
 evidence of NON-portability. I'll buy "configurable" as a descriptor
 for such ifdef'ed code, but not "portable".

 And, while I am venting about ifdef:
 As a matter of sytle, ifdefs are global constructs. Yet they often
 have local effects like an if statement. Why do we almost always
write

 #ifdef LINUX
 linux code
 #else
 default unix code
 #endif

 instead of the much cleaner

 if(LINUX)
 linux code
 else
 default unix code

 In early days the latter would have cluttered precious memory
 with unfreachable code, but now we have optimizing compilers
 that will excise the useless branch just as effectively as cpp.

 Much as the trait of overeating has been ascribed to our
 hunter ancestors' need to eat fully when nature provided,
 so overuse of ifdef echos coding practices tuned to
 the capabilities of bygone computing systems.

 "Ifdef hell" is a fitting image for what has to be one of
 Unix's least felicitous contributions to computing. Down
 with ifdef!
 Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170103/4a996b9d/attachment-0001.html>


  parent reply	other threads:[~2017-01-04  0:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-03 20:19 Doug McIlroy
2017-01-03 21:05 ` Charles Anthony
2017-01-03 21:33   ` [TUHS] When was #if introduced in C? (was: Re: Mac OS X is Unix) Michael Kjörling
2017-01-03 21:53     ` Robert Swierczek
2017-01-03 21:57       ` Clem Cole
2017-01-03 21:56     ` Clem Cole
2017-01-03 21:35 ` [TUHS] Mac OS X is Unix Clem Cole
2017-01-03 22:10   ` Lyndon Nerenberg
2017-01-03 21:39 ` Lyndon Nerenberg
2017-01-03 22:12   ` ron minnich
2017-01-03 23:39     ` Tim Bradshaw
2017-01-04  0:12       ` ron minnich
2017-01-04  9:11         ` Tim Bradshaw
2017-01-04 10:04           ` Álvaro Jurado
2017-01-04  0:13 ` Steve Johnson [this message]
2017-01-04  3:50 ` Dan Cross
2017-01-04 12:26   ` Tim Bradshaw
2017-01-04 13:49     ` Random832
2017-01-04 15:02     ` Dan Cross
2017-01-04 17:14       ` tfb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74a6eaa2dc832b400b58a56a4fa1f4bc00398314@webmail.yaccman.com \
    --to=scj@yaccman.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).