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>
next prev 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).