I know it's bad preprocessor magic, but I kinda liked that. I thought about hacking together a quick "Oberon-ish" to JS "transpiler" for a while, of course going along with a decidedly Wirth-ian code style. I might call it "werenotwirthy".

But there's also the appeal of the dreaded Incunabulum...

    #define TYPE typedef
    #define STRUCT TYPE struct
    #define UNION TYPE union

Well, that's extremely opinionated. Which I guess is the point. It does seem to add a BASIC-ness to the code.

However, when I see landmines like these:

    #define TRUE (-1)
    #define FALSE 0

I might just hide instead of touching it.

It's an ALGOL-derivative, not a BASIC-derivative. It's trying to be ALGOL. Bourne was one of the few people to write an ALGOL-68 compiler.

I might just hide instead of touching it.

This code (the Bourne Shell source) is actually the reason why the IOCCC was created.

Uh... This is serious landmine... I suggest author to change this.

This particular code isn't about the post. It's about Bournegol, which doesn't actually exist anymore, and is actually quite hard to track down any examples of.

It's...not, though? The Bourne Shell was released under a free license years ago along with the rest of v7, and it's just a macro hack. Very much still exists, and pretty easy to find.

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh

The author is 76, and retired. This is from UNIX v7, before the standardization of C.

Don't bash it til you understand it.

Can you explain why?

On C language an expression which evaluates to any non-zero value is considered as True. So for example this kind of statement would not likely behave as intended:

    if (TRUE == expression)
    {
        ...
    }

I have refused to hire people who did this. (FALSE, too, even though it is safer.)

To emphasise: This is about Bournegol. Nothing to do with this post.

> Can you explain why?

Because it isn't how most C libraries expect true/false to be defined.

stdbool in C99 standardized things a bit, but before then what was generally accepted was:

> true is 1

> false is !true (Often 0 in practice).

Which means that any trivial:

    if(true) { ... }

Won't work under Bournegol. Instead you _need_ to compare when doing an if statement.

So the C-programmer is easily tripped up. False will work as expected, but True won't... All the time. There may be times it does work. Leaving the programmer throwing their hands in the air.

Any nonzero integer is considered true in that expression, so if(TRUE) still works.

Most cases I've seen accept anything as true as long as the LSB is 1, and quite strictly 0 as false. Everything else is up in the air. The value -1 is definitely true. :)

One could say that -1 is the truest true, because its two's-complement representation has the most 1s.

True.

> The value -1 is definitely true

Except when being used as a comparison to any of the std utilities.

As far as I know, std library specifically uses the word "nonzero" in the documentation to denote non-false value. Therefore you should be using !, &&, || for any boolean ops, but never == nor !=

this is utter nonsense. in C, since before C89, all non-zero values are considered true in conditional contexts (if, for, while, ?:). http://port70.net/~nsz/c/c89/c89-draft.html#3.6.4.1. false must therefore be exactly zero. !1 is also always 0, as it must be. http://port70.net/~nsz/c/c89/c89-draft.html#3.3.3.3.

Ah. Thanks for the explanation.