12 ms·

Nah. I use C a lot, but none of this is enough to make C safe. You really need the language and the tools to enforce discipline. Oh, and things like the clea

Nah. I use C a lot, but none of this is enough to make C safe. You really need the language and the tools to enforce discipline. Oh, and things like the cleanup attribute are not standard C either, so this is not portable code.

throwawaymaths 2y ago
usually portability in C includes the provision that you can drop in whatever #includes you want?
- cryptonector 2y ago
  No, it's really not that simple at all.
  - throwawaymaths 2y ago
    Probably depends on the macro, but ok.
    - pjmlp 2y ago
      It starts by discovering how little most folks know from ISO C legalese versus what their compiler does, and it goes from there when adding anything else not part of the standard library.
imtringued 2y ago
I didn't see anything new either. What I would expect from C developers is this: * Run all CI with UBSAN. Create versions of popular distributions that build every single package with UBSAN just to catch the bugs. * Use design by contract patterns for pre and postconditions (library induced UB is popular in C++) * Use model checking software like CBMC to statically guarantee the absence of UB and validity of the contracts * Build a fuzzer for every method that cannot be formally verified This is the bare minimum needed to keep C/C++ safe. The same applies to unsafe Rust by the way.
- cryptonector 2y ago
  I'd expect something like a super-C that provides a counted-byte string (still NUL-terminated for interoperability) type and support functions, `defer` or similar, `with`-like macros, etc., `mutable`/`immutable`. Such a thing could be like C++ was in the beginning: a front-end that translates to C99 or whatever standard is your lowest common denominator. You'd still have to do manual memory management, so you'd still have use-after-free issues, but they'd be a lot less common. Similarly you'd still have races, but a lot fewer.

throwawaymaths 2y ago

usually portability in C includes the provision that you can drop in whatever #includes you want?

cryptonector 2y ago
No, it's really not that simple at all.
- throwawaymaths 2y ago
  Probably depends on the macro, but ok.
  - pjmlp 2y ago
    It starts by discovering how little most folks know from ISO C legalese versus what their compiler does, and it goes from there when adding anything else not part of the standard library.

imtringued 2y ago

I didn't see anything new either. What I would expect from C developers is this: * Run all CI with UBSAN. Create versions of popular distributions that build every single package with UBSAN just to catch the bugs. * Use design by contract patterns for pre and postconditions (library induced UB is popular in C++) * Use model checking software like CBMC to statically guarantee the absence of UB and validity of the contracts * Build a fuzzer for every method that cannot be formally verified This is the bare minimum needed to keep C/C++ safe. The same applies to unsafe Rust by the way.

cryptonector 2y ago
I'd expect something like a super-C that provides a counted-byte string (still NUL-terminated for interoperability) type and support functions, `defer` or similar, `with`-like macros, etc., `mutable`/`immutable`. Such a thing could be like C++ was in the beginning: a front-end that translates to C99 or whatever standard is your lowest common denominator. You'd still have to do manual memory management, so you'd still have use-after-free issues, but they'd be a lot less common. Similarly you'd still have races, but a lot fewer.