5 ms·

The C philosophy is captured in http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10...

by qznc 14y ago

The C philosophy is captured in http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10... "Some of the facets of the spirit of C can be summarized in phrases like: • Trust the programmer. • Don’t prevent the programmer from doing what needs to be done. • Keep the language small and simple. • Provide only one way to do an operation. • Make it fast, even if it is not guaranteed to be portable. "

pjmlp 14y ago
- Make it easy to write buffer exploits
- lihaoyi 14y ago
  - Off-by-one errors should be security vulnerabilities, rather than just crashes
  - DennisP 14y ago
    Can't say I agree. You tend to find crashes pretty quickly. Security vulnerabilities tend to be found later in much more embarrassing ways.
    - jff 14y ago
      I'm pretty sure he was joking, in the same spirit as the comment one level up.
- wslh 14y ago
  And the software that protects from them.
  - pjmlp 14y ago
    A language that allows buffer exploits cannot by definition protect you from them, because the tooling is unsound.
    - wslh 14y ago
      Yes it can, the proof is the security software that is written to do that in C/C++. Nobody is saying that the protection will protect you over all possible buffer exploits.
      - pjmlp 14y ago
        There are no guarantees that the security software is not exploitable given the quicksand it is built on.
        wslh 14y ago
        What's the difference to my comment? I didn't make any assertion about warranties.
        pjmlp 14y ago
        From Computer Science point of view if you are writing bug verification tools in an unsafe language, there is no guarantee the verification tool is giving safe results back. The same unsafe constructs can cause memory corruption in the verification tool and lead to a behavior where the wrong decisions are taken. So the fact that many C verification tools are written in C itself does not proof anything about how safe the language could be. For me personally C could be much better if: - There was no automatic decay from arrays into pointers (call an explicit operation to do so, like &a[0]) - There was a proper string type available - Arrays were bound checked (with optional disabling of bound checking, like many other languages offer)
        wslh 14y ago
        I have studied computer science, thanks. You are arguing against something I never said.

by qznc 14y ago

pjmlp 14y ago

- Make it easy to write buffer exploits

lihaoyi 14y ago
- Off-by-one errors should be security vulnerabilities, rather than just crashes
- DennisP 14y ago
  Can't say I agree. You tend to find crashes pretty quickly. Security vulnerabilities tend to be found later in much more embarrassing ways.
  - jff 14y ago
    I'm pretty sure he was joking, in the same spirit as the comment one level up.
wslh 14y ago
And the software that protects from them.
- pjmlp 14y ago
  A language that allows buffer exploits cannot by definition protect you from them, because the tooling is unsound.
  - wslh 14y ago
    Yes it can, the proof is the security software that is written to do that in C/C++. Nobody is saying that the protection will protect you over all possible buffer exploits.
    - pjmlp 14y ago
      There are no guarantees that the security software is not exploitable given the quicksand it is built on.
      - wslh 14y ago
        What's the difference to my comment? I didn't make any assertion about warranties.
        pjmlp 14y ago
        From Computer Science point of view if you are writing bug verification tools in an unsafe language, there is no guarantee the verification tool is giving safe results back. The same unsafe constructs can cause memory corruption in the verification tool and lead to a behavior where the wrong decisions are taken. So the fact that many C verification tools are written in C itself does not proof anything about how safe the language could be. For me personally C could be much better if: - There was no automatic decay from arrays into pointers (call an explicit operation to do so, like &a[0]) - There was a proper string type available - Arrays were bound checked (with optional disabling of bound checking, like many other languages offer)
        wslh 14y ago
        I have studied computer science, thanks. You are arguing against something I never said.