DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:30 UTC (Tue) by nye (guest, #51576)
In reply to: DeVault: Announcing the Hare programming language by NYKevin
Parent article: DeVault: Announcing the Hare programming language

> things like optimizing out NULL checks if you can prove that the pointer was previously dereferenced

This sort of thing is exactly why we shouldn't be asking for languages which "trust the programmer". By dereferencing a pointer, according to the rules of C, the programmer is instructing the compiler that it can assume the pointer is not null. It seems churlish to then turn around and complain that the compiler took you at your word.

to post comments

DeVault: Announcing the Hare programming language

Posted May 3, 2022 14:01 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (3 responses)

Quite the opposite. In practice I *know* that dereferencing a NULL on any modern platform causes a SEGV and I'm using it exactly for that purpose. In C that's UB so compilers decided that since the program doesn't exist afterwards it's not their problem and they can eliminate the code. Except that my code was there precisely to provoke a panic and crash the program before it degenerates, while still preserving registers and frame pointer intact. Using abort() is not an option for this (it ruins everything and sometimes you can't even unwind the stack when you're mailed the core using on libs that are not exactly yours). Result: I had to cheat and dereference (int*)1 because the compiler didn't know it was NULL as well. It's constantly a can-and-mouse game between C developers and compiler developers, with the former saying "let me use my processor and OS for the purpose they were built" and the latter saying "we don't want you to do that because that's stupid". It may be stupid from a compiler developer's point of view, but if all C developers were compiler developers we wouldn't need gcc nor clang and would each one develop our own compiler. So please let us dictate the compiler what we want to do so we can use our hardware in peace.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 14:44 UTC (Tue) by excors (subscriber, #95769) [Link]

> In practice I *know* that dereferencing a NULL on any modern platform causes a SEGV and I'm using it exactly for that purpose.

That depends on what you consider a modern platform - there are ARMv8-M microcontrollers where address 0 is the start of flash, and reading NULL will return some non-zero data (because that's where the vector table is stored). (Writing to NULL might raise an exception or actually modify flash, depending on the current configuration of the flash controller.)

> Except that my code was there precisely to provoke a panic and crash the program before it degenerates

If you're explicitly writing to NULL, Clang will optimise it away but helpfully tells you:

> warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference]
> *(int *)0 = 0;
> ^~~~~~~~~
> note: consider using __builtin_trap() or qualifying pointer with 'volatile'

volatile prevents the optimisation, so it will emit the write instruction. __builtin_trap typically emits an undefined instruction (ud2 on x86), which will crash even on systems where 0 is a valid address.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 15:18 UTC (Tue) by nye (guest, #51576) [Link]

Oh come on - you're talking about deliberately writing something that you know is invalid in the chosen language and then complaining that the compiler implementer didn't do what you mean. And *then* getting angry about them not trusting you! I don't see how anyone could consider this a defensible position.

Do What I Mean

Posted May 3, 2022 16:27 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Rather than "let me use my processor and OS for the purpose they were built" what you actually seem to want, though you don't seem aware of it, is "Do What I Mean" which is not deliverable, hence why you're unsatisfied.

First of all you will need to write what you meant, if you can do that, compilers can produce programs that do what you wrote and you'll be satisfied. But most often unhappy C programmers find that they really struggle to write what they meant, and that's where the problem lies, because if you can't write what you meant, then a program which does what you wrote won't do what you meant and you'll be unhappy.