Falsehoods programmers believe about null pointers

[litchralee@sh.itjust.works]

I read this, and thought it was kind of all over the place. Even the first "falsehood" about immediately crashing is answered as "true for some languages but not some others". Even just the motion of superlatives in CS like "always" and "never" rarely hold, including this very sentence and almost certainly when talking about multiple programming languages.

And on that point, it's a minor quibble, but while Go's nil pointers are similar to C null pointers and Rust's null raw pointers, it's a strange thing to have the title be about falsehoods about null pointers.

But then much of the other supposed falsehoods are addressed only for the C language, such as null deference being UB or not.

9. On platforms where the null pointer has address 0, C objects may not be placed at address 0.

I would like to see a (C)itation [pun intended] for this being a falsehood, since my understanding is that if an implementation uses 0x0 as the null pointer, then the check for a null pointer is to check if it's equal to 0x0, which would require that no "thing" in C use that address.

[marcos@lemmy.world]

I'm almost sure storing data at *(0) is undefined behavior, so yes, that falsity #9 is indeed false.

Also, many embedded toolsets expect you to write there.

[drspod@lemmy.ml]

Macromedia Flash Action Script was the first language I saw that could have a RCE vulnerability caused by null pointer dereference.

Thank god HTML5 media killed Flash.

[chaospatterns@lemmy.world]

Flash isn't dead yet.

I just had to use it to connect to an ancient Siemens building automation system. Luckily we're replacing it this year.

[fizzyorange@programming.dev]

Before virtual memory was a thing, almost all memory was accessible.

Virtual memory has nothing to do with whether 0 is a valid address. You can have a CPU where it is valid, or one where it isn't and you'll get an access fault if you try to access it. You can also have virtual memory where page 0 is mappable, or not.

[fizzyorange@programming.dev]

Small nit:

CHERI is even weirder. CHERI pointers store
128-bit capabilities in addition to the 64-bit address we’re used to

The 128-bit capability (actually 129 since there's a tag bit) includes the address. It's 64-bit address + 64-bit metadata + 1-bit tag = 129-bit capability.

[drspod@lemmy.ml]

Thanks, I'm going to have nightmares tonight.

[giooschi@lemmy.world]

FYI there is an open source reimplementation of Flash from scratch called Ruffle that should solve all the security issues that Flash had. It runs on WASM so it's compatible with modern browsers. The New York Times is using it to bring back some old interactive/animated pages that relied on Flash.

[refalo@programming.dev]

Very misleading writing style IMO. I would say most of their bullet points ARE actually true in most cases... they just keep bringing up somewhat rare/exotic exceptions as a way to call it a "falsehood".

[corbin@programming.dev]

A claim which is mostly true is false. Programmers should pay attention to details, since that is all computers know.

[refalo@programming.dev]

Details like the fact that people can have differing opinions and perspectives, and should not speak in absolutes?

[talkingpumpkin@lemmy.world]

Details such as that accepting the statement "a claim which is mostly true is false" means that "a claim which is mostly false is true" must also be accepted (that one, or "a claim which is sometimes true is true" depending on what you think "not (mostly true)" means)

[fades@lemmy.world]

Not everything can be easily boxed into Boolean categories so no, a mostly true claim is not simply false. You are erasing the key context and nuance to make this foolish absolute statement.