On Tue, Jan 3, 2017 at 3:19 PM, Doug McIlroy &lt;doug(a)cs.dartmouth.edu&gt; wrote: ​I hear you and partially agree. But I would point out that my experience in 40+ years of professional "coding" the programs that have "lasted" the longest and matured the most over time, were all written in a language that had some sort of preprocessor.​ Using a preprocessor is not a bad thing, it's the miss use that is the problem and leaving it out I think weakens the language. IIRC: Brian made this same point in the "Why Pascal is not my Favorite Programming Language." I think your point of over use, is valid (like symlinks in the file system - my curmudgeonly beef) - just because we >>have<< a feature does not make it the best way to do something. I like to think of this sort of choice as "good taste" -- simple and elegant. ifdef's are a real solution to a problem. But like you, I >>hate<< seeing them all over the place and they certainly can muck up the code. BTW: I much prefer a local_func.c which sucks in unix_bindings.c, vms_bindings.c, winders_bindings.c or the like with ifdefs and alls the configuration control needed in >>one<< place; and then all of the rest of the code try to be a pure as possible as you describe. FWIW: One of the best I ever saw was the old FORTRAN SPICE 2G6 of Ellis Cohen and Tom Quarles. That program runs everywhere (still does). Ellis and Tom used m4 to preprocess it, IIRC and keeps the localization in a very controlled space. If you even looked at it, Ellis does some really imaginative coding (compiling the internal loop in a data block and jump to it), it all portable and actually very easy to understand. For one thing the comments are there and very, clear. But Ellis has great style and have mopped up after a number of other of the UCB greats in those days, I'd much rather deal with Ellis's and TQ's code base then some of my other peeps. Anyway - I agree - ifdef >>is<< miss used in way too much code, but I think part of that is so many programmers never had a real software engineering course ( a thought I will follow up in another thread). Clem

Plan 9 refreshingly evicted this nonsense from the native compilers (mostly) and the code base.[1] I remember reading a Usenet post from the mid-late 80s that showed a roughly 40 line sequence of #foo hell from some bit of SVRx code. There wasn't a single line of actual C there. That it involved conditionalizing around the tty/termio drivers and some machine-specific ioctl goop ... well, let's not go *there*. It might have been posted as an example for the Obfuscated C Contest. It certainly could have won. (Assuming an entry without any actual C code was eligible. Vague memories say anything that survived 'cc -o foo xxx.c [...]' was allowed.) --lyndon [1] Eliminating many binary APIs -- e.g. ioctl() -- in favour of textual ones, was a stroke of genius. Not just with fileservers (/net et al), but also with things like dial().

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" &lt;doug(a)cs.dartmouth.edu&gt; To:<tuhs@minnie.tuhs.org> Cc: Sent:Tue, 03 Jan 2017 15:19:08 -0500 Subject:Re: [TUHS] Mac OS X is Unix requires 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