5 ms·

You say that as if that's a bad thing – I absolutely need to kept safe from myself, because I need all the help I need to make sure I'm doing things right!

• sargstuff 3y ago
  use a malloc that has the extra saftey features, run under an interpreted C, and several other ways to handle it (sandbox program, emulator, etc). Changing the underlying C language should NOT be one of them.
  • AlotOfReading 3y ago
    The only way to make C "safe" without modifying the language is to run it in a VM, and even that doesn't fully encompass what people mean by safety. It's an old language. Some of the fundamental mistakes were just things that were common at the time and only look so bad in hindsight (e.g. strings, locales, nullable pointers, half the k&r standard library). That doesn't mean we can't and shouldn't do better where we can though.
    • pjmlp 3y ago
      Example, C++/CLI, if certain code patterns are used the code is no longer considered safe from MSIL verifier point of view. C and C++ targeting WASM, despite all the security message of how great it is, memory locations inside of the same linear memory segment can still be corrupted, thus providing a way to influence the overall execution logic inside of the sandbox.
    • sargstuff 3y ago
      Oh, so time of 4k memory, have a 4k program and want to strictly reserve/add 3.14159 K to 4k program for automated saftey issues? At time C was written, swapping in/out of memory measured in literal minutes & when fraction of second of execution time, including swapping in/out of memory, was more than several times the average yearly salary of the day (excluding sneaker net intervention)
• zh3 3y ago
  I'd agree with that, to the extent that understanding how badly your tools can hurt you is an important thing to learn. Consider how a surgeon would respond if told not to use a scalpel because of the risk of accidental injury when using a sharp tool. We learn from our mistakes - to which I'd add, sometimes we can afford to make mistakes (home programs) and other times we can't (safety-critical code).
  • ilyt 3y ago
    Surgeon would absolutely use a tool that tells them when they're about to make something that's 99% of the time a mistake.
  • ecshafer 3y ago
    I think a more accurate analogy would be some kind of scalpel that would not let the surgeon cut deeper than they needed. So if they needed a 1 cm incision, it would somehow stop the blade form going in 1.1 cm. In that case, some experienced surgeon may say "But I know how to make a 1cm incision!", but I think that the reality is that preventing a mistake from happening is valuable. You see the same arguments against static analysis, unit tests, strong type systems, etc. The evidence seems to favor systems which prevent errors over artisinal expertise.
    • Kamq 3y ago
      I think an even more accurate analogy would be if a surgeon had some kind of scalpel with a 1 cm limit, but if a surgery suddenly changes in the middle, and suddenly requires a deeper incision, the surgeon has to spend a non-zero amount of time re-configuring the scalpel. This casts flexibility vs safety as a tradeoff, which it is.
      • SilasX 3y ago
        Oh, one more refinement: Surgeons are constantly killing people[1], and every time, it turns out it was because the surgeon disabled a known, recommended safety rail, and whenever anyone points out that they should stop disabling the safety rails, they insist that they know how to operate without them, it's those other people that don't. Plus it's sooooo inconvenient for an operation[2] to take five more minutes, they're too good to have to deal with that. [1] introducing security vulnerabilities [2] code changeset submission