[TUHS] Mac OS X is Unix

ron minnich rminnich at gmail.com
Wed Jan 4 10:12:04 AEST 2017

On Tue, Jan 3, 2017 at 3:39 PM Tim Bradshaw <tfb at tfeb.org> wrote:

> I think you can do so only if every language processor you ever expect to
> deal with your code is lexically-compatible: you *can't* do so if the lexer
> will puke: you need some frontend which will prevent the lexer ever seeing
> the toxin, and that thing is what Lisp would call read-time
> conditionalization.  Plan 9 and Go both avoid this problem by being
> single-implementation or nearly-single-implementation systems: many things
> are easier with that assumption.
Well, if by single-implementation, you mean single-compiler, I have a
counter example: Harvey is Plan 9 with just enough changed to be C11
compliant. All of userland, libraries, and kernel build and boot with gcc
4, 5,6 and clang 3.5, 3.6, and 3.8. Harvey builds and boots on amd64 and
riscv. We've adhered as much as we can to the coding style of Plan 9 and
we've seen the benefits. Probably the only major change was removal of
anonymous struct members, and that actually improved the code as it
uncovered some long-standing driver bugs.

In contrast, it's very hard to build portable code that uses extensive
ifdefs and 'modern' tools like libtool today. Just the other day I had a
 build failure because something needed autotools x.6.61 and I only had
x.y.60. Portable seems to now mean 'builds on ubuntu AND Fedora!' and even
that's rare.

The portability principles used in Plan 9 work just fine with 'modern'
compilers. The cpp abuse we see in so much code today seems completely
unnecessary to me. C code written with #ifdefs and libtool is far less
portable than it might be.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170104/8eb183c4/attachment.html>

More information about the TUHS mailing list