Comment by layer8
18 hours ago
> no array bounds checking is possible.
This isn’t strictly true, a C implementation is allowed to associate memory-range (or more generally, pointer provenance) metadata with a pointer.
The DeathStation 9000 features a conforming C implementation which is known to catch all array bounds violations. ;)
> The DeathStation 9000 features a conforming C implementation which is known to catch all array bounds violations. ;)
That actually really does exist already with CHERI CPUs, whose pointers are tagged with "capabilities," which catch buffer overruns at runtime.
https://tratt.net/laurie/blog/2023/two_stories_for_what_is_c...
https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/
Right. Also it might it sound like array-to-pointer decay is forced onto the programmer. Instead, you can take the address of an array just fine without letting it decay. The type then preserves the length.
C: int foo(int a[]) { return a[5]; }
Oops.
D: int foo(int[] a) { return a[5]; }
Ah, Nirvana!
How to fix it for C:
https://www.digitalmars.com/articles/C-biggest-mistake.html
You need to take the address of the array instead of letting it decay and then size is encoded in the type:
Or for run-time length:
https://godbolt.org/z/dxx7TsKbK\*
Nice, when you know the length at compile time, which is rarely from my experience.
The holy grail is runtime access to the length, which means an array would have to be backed by something more elaborate.
Oh, it also work for runtime length:
https://godbolt.org/z/PnaWWcK9o
2 replies →
A worked example: https://github.com/pizlonator/llvm-project-deluge/blob/delug...
"The DeathStation 9000"
The what now?
Nasal daemons for those of us of a slightly older vintage ...
Google it.
Yeah, why have any type of human interaction in a forum when you can just refer your fellow brethren to the automaton.
2 replies →