←back to thread

The C23 edition of Modern C

(gustedt.wordpress.com)
415 points bwidlar | 1 comments | | HN request time: 0.439s | source
Show context
ralphc ◴[] No.41851601[source]
How does "Modern" C compare safety-wise to Rust or Zig?
replies(4): >>41852048 #>>41852113 #>>41852498 #>>41856856 #
WalterBright ◴[] No.41852113[source]
Modern C still promptly decays an array to a pointer, so no array bounds checking is possible.

D does not decay arrays, so D has array bounds checking.

Note that array overflow bugs are consistently the #1 problem with shipped C code, by a wide margin.

replies(1): >>41852316 #
layer8 ◴[] No.41852316[source]
> 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. ;)

replies(4): >>41852348 #>>41852932 #>>41854734 #>>41855111 #
uecker ◴[] No.41852348[source]
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.
replies(2): >>41853029 #>>41854211 #
codr7 ◴[] No.41853029[source]
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.

replies(1): >>41856489 #
uecker ◴[] No.41856489[source]
Oh, it also work for runtime length:

https://godbolt.org/z/PnaWWcK9o

replies(1): >>41856543 #
1. pjmlp ◴[] No.41856543[source]
Now try that on a compiler without -fsanitize=bounds, yet full ISO C compliant.