4 Jan
2017
4 Jan
'17
6:12 a.m.
On Tue, Jan 3, 2017 at 3:39 PM Tim Bradshaw <tfb(a)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.
ron