9 ms·

95% of the supposed issues with C could be solved by a new standard library, integrating the debugger into the compiler as the default build/run environment (w

95% of the supposed issues with C could be solved by a new standard library, integrating the debugger into the compiler as the default build/run environment (with auto address sanitisation, frame protection, etc. etc.), and a default strict mode error checking. It would then be actually really hard to successfully run a C program (in the debugger) with any problems. Under these conditions it'd be easy to imagine most C programs running with fewer bugs (, leaks, etc.) than Rust programs.

pjmlp 2y ago
Except it is easier to introduce a new programming language than having a committee driven language to adopt a new standard library. Neither ISO nor OpenGroup would care about it. Remember that since 1989, no actions were taken to improve its security. Even the few functions that have been added still use pointer/length pairs without any means to validate they are the correct pair.
- Someone 2y ago
  > Remember that since 1989, no actions were taken to improve its security. Not much, but not nothing, either. gets was deprecated in C99 and removed in C11 (https://en.wikipedia.org/wiki/C_file_input/output#gets https://en.wikipedia.org/wiki/C_file_input/output#gets)
  - pjmlp 2y ago
    Yet the scanf and fgets possible exploits are still there.
- rdpintqogeogsaa 2y ago
  > Remember that since 1989, no actions were taken to improve its security. Technically, gets() was removed from the standard library in C11[0]. However, that is far from a semantically meaningful overhaul of the standard library. I nonetheless felt the need to point out that there was a very specific effort for the sake of completeness. [0] https://en.cppreference.com/w/c/io/gets https://en.cppreference.com/w/c/io/gets
  - pjmlp 2y ago
    Which is great, except for all those stubborn folks not using anything beyond C99, and scanf and fgets are still possible attack vectors, when getting sizes wrong.
    - ctoshiningc 2y ago
      Have you tried talking to them?
- nine_k 2y ago
  Create a language with semantics exactly like C, but the standard library completely replaced. Call it in a way that avoids trademark disputes (e.g. CWSL, C With Sane Library). Get GCC and LLVM support it, which should be reasonably easy, because both support compiling code that does not rely on libc (though OS entry point code, etc should be wired in). Would it be easy enough to port important C code to it, given that most of the libc-supplied functions, and functions transitively depending on these, would have to be rewritten? Would it be worthwhile, compared to rewriting such code it in Zig, Rust, or Ada?
  - pjmlp 2y ago
    There have been multiple attempts at this, how many folks heard of Safe-C, C3,... ? Only bothering to list two examples, there are many others, even Cyclone is partially C compatible, guess what came out of Cyclone.
    - oguz-ismail 2y ago
      >Safe-C import statements are a deal breaker >C3 shit syntax >Cyclone vaporware
      - MyOutfitIsVague 2y ago
        Why in the world would import statements be a deal breaker?
        oguz-ismail 2y ago
        > The .h and .c files of a component must always be stored in the same folder so that the compiler can find them
        pjmlp 2y ago
        Learn to use your compiler switches.
  - 2y ago
- chrsig 2y ago
  eh, i think i disagree. a new stdlib on its own wouldn't come with a lot of abi/linking baggage that tends to hold up tooling and migrations when you start introducing a different language. (see recent rust/linux drama). i mean, if the committee members can make it happen or not, i don't know. but it's still a worthy thing to explore, I think. there's going to be a lot of C code that will need a very gradual migration path to safer apis for a very very long time.
Keyframe 2y ago
might as well throw in MISRA-C checker into it.
oliverkwebb 2y ago
The core of C is pointer arithmetic; This creates a fundamentally unsafe environment. You can't even do anything in C without some asm (syscall wrappers) because C was meant to boil down and streamline PDP-11 assembly (Your computer is not a fast PDP-11) to a set of consistent principles. The consequence of this is that the core of the language is pointers and pointer arithmetic, and raw unabstracted pointers are fundamentally unsafe to work with. Using the rust type system I can essentially confirm code is bug and edge-case free with exhaustive matching and unit testing (C's lack of tooling blessed the world with autoconf and cmake btw). Not to mention rusts ability to abstract away necessary boilerplate gives me more time to think about my code instead of pointer arithmetic and allocation heuristics. The "cure" for C is a language that abstracts away raw pointers and memory allocation.
- oguz-ismail 2y ago
  > You can't even do anything in C without some asm (syscall wrappers) Which language can do anything without some asm and support as many platforms as C?
  - oliverkwebb 2y ago
    > Which language can do anything without some asm and support as many platforms as C? I wouldn't be surprised if someone figured out how to do the interrupts and register control necessary to invoke syscalls with pure LISP/Scheme/CL :P P.S. anything that compiles with LLVM and has an ingrained way to do print() that doesn't invoke libc, although there's a blurry line here between "pure asm"/"compiles to asm" that involves trusting-trust-style bootstrapping of features into the compiler
    - oguz-ismail 2y ago
      You don't know what you're talking about
    - nolist_policy 2y ago
      > > Which language can do anything without some asm and support as many platforms as C? > I wouldn't be surprised if someone figured out how to do the interrupts and register control necessary to invoke syscalls with pure LISP/Scheme/CL :P Haha > P.S. anything that compiles with LLVM and has an ingrained way to do print() that doesn't invoke libc, although there's a blurry line here between "pure asm"/"compiles to asm" that involves trusting-trust-style bootstrapping of features into the compiler Actually LLVM IR has no concept of syscalls, you have to use inline assembly inside your IR to issue syscalls.
ctoshiningc 2y ago
The Rust Evangelism Strike Force clearly hasn't been defunded by DOGE (yet). Respectfully, if you want to use Rust, just use Rust. If C doesn't suit you, you don't have to use it, and you don't have to make unreasonable demands of the standards body.
josephg 2y ago
I think this is a really good idea, and zig shows how it could work. But this? > Under these conditions it'd be easy to imagine most C programs running with fewer bugs (, leaks, etc.) than Rust programs. This is a crazy goal. You will never out-rust rust by adding a few runtime checks to C, while in debug mode. Fewer bugs than rust code is a wild goal. I don’t think you understand just how much rust’s design prevents you from shipping bugs. It’s due to a combination of so, so many things. Like: references instead of pointers, unsafe blocks, sum types & match instead of unions, no implicit nullability, unwrapping optional values is explicit, the result type and #[must_use], bounds checks, the borrow checker preventing use after free, ownership semantics, Send & Sync for thread safety, and I’m sure plenty more. It’s common to write very complex, threaded rust code and have it work first time. Well, the first time it compiles. Coming from C, it’s wild. Or, really, just about any other language. To get the same result in C wouldn’t just need a “strict mode”. You would need to ban raw pointers - which would make it no longer C. And you’d need to make functions return more than an (easily ignored) status code. Ie, you want a result type. For bounds checking, you’d need a language level data structure for slices / arrays (pointer + length). You’d have to do away with void pointers for “generic” parameters. And probably 100 other tiny, breaking changes that the C community will never accept. And for all that, you would essentially get zig. Zig does all these things. But that would still get you worse bug density than rust because you don’t have a borrow checker. It’ll get you close - Runtime checks in debug mode will detect your use after frees - if you have a good test suite. But they won’t prevent aliasing. Or (I think) help with thread safety. For that, you need a borrow checker. You need rust.
- mjburgess 2y ago
  We're talking about different kinds of bugs. One claim i'm making here is the poor iteration time imposed by Rust's complexity, significant design constraints, and so on, themselves cause kinds of bugs which are more readily addressed in C. Eg., I think memory leaks are easier in std Rust than in the kind of C i'm talking about. I don't think we have a good evidential basis for comparing the total class of programming bugs in Rust vs. comparable langs -- since there isn't that much Rust code. One "empirically ambitious" claim here is that the very high complexity of rust isn't design-bug-free, and "getting to 95%" with a modern C toolchain retains a very low-complexity get-it-done-and-iterate style of programming which has many "bug free'ing" advantages. Esp. if supported by a "debugger-oriented std lib"

pjmlp 2y ago

Except it is easier to introduce a new programming language than having a committee driven language to adopt a new standard library. Neither ISO nor OpenGroup would care about it. Remember that since 1989, no actions were taken to improve its security. Even the few functions that have been added still use pointer/length pairs without any means to validate they are the correct pair.

Someone 2y ago
> Remember that since 1989, no actions were taken to improve its security. Not much, but not nothing, either. gets was deprecated in C99 and removed in C11 (https://en.wikipedia.org/wiki/C_file_input/output#gets https://en.wikipedia.org/wiki/C_file_input/output#gets)
- pjmlp 2y ago
  Yet the scanf and fgets possible exploits are still there.
rdpintqogeogsaa 2y ago
> Remember that since 1989, no actions were taken to improve its security. Technically, gets() was removed from the standard library in C11[0]. However, that is far from a semantically meaningful overhaul of the standard library. I nonetheless felt the need to point out that there was a very specific effort for the sake of completeness. [0] https://en.cppreference.com/w/c/io/gets https://en.cppreference.com/w/c/io/gets
- pjmlp 2y ago
  Which is great, except for all those stubborn folks not using anything beyond C99, and scanf and fgets are still possible attack vectors, when getting sizes wrong.
  - ctoshiningc 2y ago
    Have you tried talking to them?
nine_k 2y ago
Create a language with semantics exactly like C, but the standard library completely replaced. Call it in a way that avoids trademark disputes (e.g. CWSL, C With Sane Library). Get GCC and LLVM support it, which should be reasonably easy, because both support compiling code that does not rely on libc (though OS entry point code, etc should be wired in). Would it be easy enough to port important C code to it, given that most of the libc-supplied functions, and functions transitively depending on these, would have to be rewritten? Would it be worthwhile, compared to rewriting such code it in Zig, Rust, or Ada?
- pjmlp 2y ago
  There have been multiple attempts at this, how many folks heard of Safe-C, C3,... ? Only bothering to list two examples, there are many others, even Cyclone is partially C compatible, guess what came out of Cyclone.
  - oguz-ismail 2y ago
    >Safe-C import statements are a deal breaker >C3 shit syntax >Cyclone vaporware
    - MyOutfitIsVague 2y ago
      Why in the world would import statements be a deal breaker?
      - oguz-ismail 2y ago
        > The .h and .c files of a component must always be stored in the same folder so that the compiler can find them
        pjmlp 2y ago
        Learn to use your compiler switches.
- 2y ago
chrsig 2y ago
eh, i think i disagree. a new stdlib on its own wouldn't come with a lot of abi/linking baggage that tends to hold up tooling and migrations when you start introducing a different language. (see recent rust/linux drama). i mean, if the committee members can make it happen or not, i don't know. but it's still a worthy thing to explore, I think. there's going to be a lot of C code that will need a very gradual migration path to safer apis for a very very long time.

Keyframe 2y ago

might as well throw in MISRA-C checker into it.

oliverkwebb 2y ago

The core of C is pointer arithmetic; This creates a fundamentally unsafe environment. You can't even do anything in C without some asm (syscall wrappers) because C was meant to boil down and streamline PDP-11 assembly (Your computer is not a fast PDP-11) to a set of consistent principles. The consequence of this is that the core of the language is pointers and pointer arithmetic, and raw unabstracted pointers are fundamentally unsafe to work with. Using the rust type system I can essentially confirm code is bug and edge-case free with exhaustive matching and unit testing (C's lack of tooling blessed the world with autoconf and cmake btw). Not to mention rusts ability to abstract away necessary boilerplate gives me more time to think about my code instead of pointer arithmetic and allocation heuristics. The "cure" for C is a language that abstracts away raw pointers and memory allocation.

oguz-ismail 2y ago
> You can't even do anything in C without some asm (syscall wrappers) Which language can do anything without some asm and support as many platforms as C?
- oliverkwebb 2y ago
  > Which language can do anything without some asm and support as many platforms as C? I wouldn't be surprised if someone figured out how to do the interrupts and register control necessary to invoke syscalls with pure LISP/Scheme/CL :P P.S. anything that compiles with LLVM and has an ingrained way to do print() that doesn't invoke libc, although there's a blurry line here between "pure asm"/"compiles to asm" that involves trusting-trust-style bootstrapping of features into the compiler
  - oguz-ismail 2y ago
    You don't know what you're talking about
  - nolist_policy 2y ago
    > > Which language can do anything without some asm and support as many platforms as C? > I wouldn't be surprised if someone figured out how to do the interrupts and register control necessary to invoke syscalls with pure LISP/Scheme/CL :P Haha > P.S. anything that compiles with LLVM and has an ingrained way to do print() that doesn't invoke libc, although there's a blurry line here between "pure asm"/"compiles to asm" that involves trusting-trust-style bootstrapping of features into the compiler Actually LLVM IR has no concept of syscalls, you have to use inline assembly inside your IR to issue syscalls.

ctoshiningc 2y ago

The Rust Evangelism Strike Force clearly hasn't been defunded by DOGE (yet). Respectfully, if you want to use Rust, just use Rust. If C doesn't suit you, you don't have to use it, and you don't have to make unreasonable demands of the standards body.

josephg 2y ago

I think this is a really good idea, and zig shows how it could work. But this? > Under these conditions it'd be easy to imagine most C programs running with fewer bugs (, leaks, etc.) than Rust programs. This is a crazy goal. You will never out-rust rust by adding a few runtime checks to C, while in debug mode. Fewer bugs than rust code is a wild goal. I don’t think you understand just how much rust’s design prevents you from shipping bugs. It’s due to a combination of so, so many things. Like: references instead of pointers, unsafe blocks, sum types & match instead of unions, no implicit nullability, unwrapping optional values is explicit, the result type and #[must_use], bounds checks, the borrow checker preventing use after free, ownership semantics, Send & Sync for thread safety, and I’m sure plenty more. It’s common to write very complex, threaded rust code and have it work first time. Well, the first time it compiles. Coming from C, it’s wild. Or, really, just about any other language. To get the same result in C wouldn’t just need a “strict mode”. You would need to ban raw pointers - which would make it no longer C. And you’d need to make functions return more than an (easily ignored) status code. Ie, you want a result type. For bounds checking, you’d need a language level data structure for slices / arrays (pointer + length). You’d have to do away with void pointers for “generic” parameters. And probably 100 other tiny, breaking changes that the C community will never accept. And for all that, you would essentially get zig. Zig does all these things. But that would still get you worse bug density than rust because you don’t have a borrow checker. It’ll get you close - Runtime checks in debug mode will detect your use after frees - if you have a good test suite. But they won’t prevent aliasing. Or (I think) help with thread safety. For that, you need a borrow checker. You need rust.

mjburgess 2y ago
We're talking about different kinds of bugs. One claim i'm making here is the poor iteration time imposed by Rust's complexity, significant design constraints, and so on, themselves cause kinds of bugs which are more readily addressed in C. Eg., I think memory leaks are easier in std Rust than in the kind of C i'm talking about. I don't think we have a good evidential basis for comparing the total class of programming bugs in Rust vs. comparable langs -- since there isn't that much Rust code. One "empirically ambitious" claim here is that the very high complexity of rust isn't design-bug-free, and "getting to 95%" with a modern C toolchain retains a very low-complexity get-it-done-and-iterate style of programming which has many "bug free'ing" advantages. Esp. if supported by a "debugger-oriented std lib"