It's absolutely fine to have a packed representation of a sum type "under the hood": this is how Rust implements Option<&T> (where T: Thin), for example. It's also fine to expose the layout of this packed representation to the programmer, as C's union does. But it's a huge footgun to have unchecked casts as the default. If not for this terrible convention, C wouldn't have any unchecked implicit casts: something like f(1 + 0.5) performs a coercion, a far more sensible behaviour.
The only reason we're talking about null pointers at all is because they were an influential idea, not because they were a good idea. Likewise with the essay.
And there's nothing wrong with that! But you should write it
union {
char *ptr;
size_t scalar;
} my_nullable_pointer;
if (my_nullable_pointer.scalar) {
printf("%s", my_nullable_pointer.ptr);
}
not: char *my_nullable_pointer;
if (my_nullable_pointer) {
printf("%s", my_nullable_pointer);
}
Yes, this takes up more space, but it also makes the meaning of the code clearer. typedef in a header can bring this down to four extra lines per pointer type in the entire program. Add a macro, and it's five extra lines plus one extra line per pointer type. Put this in the standard library, and the programmer has to type a few extra characters – in exchange for it becoming extremely obvious (to an experienced programmer, or a quick-and-dirty linter) when someone's introduced a null pointer dereference, and when a flawed design makes null pointer dereferences inevitable.> The Hoare ALGOL W thing seems to be more relevant to null pointers in Java and the like.
I believe you are correct; but I like blaming Tony Hoare for things. He keeps scooping me: I come up with something cool, and then Tony Hoare goes and takes credit for it 50 years in the past. Who does he think he is, Euler?
Sort of right, sort of wrong.
From my understanding: older, simpler, architectures treat memory location zero as a normal memory address. On x86 and x64, the OS can configure the MMU to treat certain pages as invalid. Many years ago, I ran across a reference to Sparcs treating accesses to memory location zero as invalid. In other words, it depends upon which architecture you're dealing with.
This led to strange hardware implementations like "0 and 4 point to 0x800000 and 0x800004 (or wherever the ROM is) until a latch is cleared, then they point to 0" - with the latch being cleared fairly early in the boot process. This let you create a different entry point for soft and hard boot, if you wanted.
In that implementation, you could read and write to 0, once the latch was cleared.
mov rax, qword ptr [0]I didn’t start programming until a few years later, but for sure by 2002, it seemed to me a given that compilers were free. It was my impression that stuff like Borland was niche and that serious stuff like Java and C were free.
Not saying you are wrong, just your comment surprised me. Maybe I have a revisionist memory or maybe those intervening 3 years were quite transformational in the industry.
As MSFT partner, we also started our voyage to port the GUI frontends into the newly introduced .NET.
We used Red-Hat Linux internally for our CVS server, MP3 music shares and Quake lan parties.
That is how seriously we look at Linux in 2002.
Does Perl and Apache (as in httpd, not the foundation) counts?
They are shipped in many enterprisy software at those time.
., and BIND. NTP, Sendmail. They are all opensource and predates that.
Prices also varied around OS features used. Vendors loved to nickel-and-dime you (separate *-user client licenses for file services, print services, remote access, etc), generally to drive you towards bigger packages that seemed like a better deal.
But yeah imo you're closer to right than not, though Microsoft licenses were still fairly expensive.
Commercial access to Unix source was still many thousands of dollars, the whole SCO debacle was an attempt to stop free OSs from being a thing
Many of us who had grown up from the mainframe era wanted to write compilers, work on OS's etc etc it was a hard thing to do (esp. outside the US) before the late 80s, cheap commodity hardware let a thousand flowers bloom
(That's not the biggest flaw in the essay, of course. It made predictions, some of which turned out to be comically wrong. The true parts of it weren't new, and the new parts of it weren't true.)
If you take the goal as inspiring people, i think it achieved its goals and then some. I'm pretty sure that CATB brought more people into FOSS than the GNU manifesto ever did.
(2) You may have missed the link to ~1,000 words of detailed criticism of CATB, on which I support my claim here that CATB is bad.
There’s nothing I’m seeing in the text as it is written that suggests this to be the case. There are just a lot of comments I see that amount to: “I don’t like this,” which can be an interesting signal by itself but not if users refuse to elaborate on it, which is what I (erroneously) thought was happening here.
> You may have missed the link to ~1,000 words of detailed criticism of CATB, on which I support my claim here that CATB is bad.
I did miss it, sorry. I clicked through and didn’t notice that the top comment was yours. I assumed you were just linking to a past discussion.
I’m sure you already know this, but on the off chance you don’t, you can click on a comment’s timestamp to get a permalink to the specific comment, like this:
But yeah, the big thing here is that the substance of my critique is on a different thread. It's disfavored to retype things you can just link to. I'd be irritated with me too if I just said "CATB is bad!" and left it at that.
https://news.ycombinator.com/item?id=35939383