5 ms·

> This sort of thing seems (to me, at least) like a jury-rigged workaround rather than an actual solution. Really? I had a look at the code and I would agree w

> This sort of thing seems (to me, at least) like a jury-rigged workaround rather than an actual solution. Really? I had a look at the code and I would agree with the basic idea of eliminating errno and always using the return value. > If you actually care about memory safety—which you should, as the CVE list shows—then why not use an actual memory-safe language? Following the logic here, you seem to be implying that no-one except the irresponsible should use C.

geofft 10y ago
> Following the logic here, you seem to be implying that no-one except the irresponsible should use C. This seems highly likely, yes. C was a good language at the time. It's still probably a very good teaching language for systems programming. But it's a bad language for anyone who wants to write software that needs to be used responsibly. It predates the entire idea that some people on the network might be hostile. It predates the knowledge that buffer overflows might be used for malice. It predates about 40 years of programming language research and security research, some of which has even shown results. C also predates computers of modern speed; it was written at a time when interpreted languages were mostly unthinkable for serious software. There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today, but it was presumably the best tool for the job at the time. It is no criticism of C to say that it has served us well but it is a bad choice for new software for clear and objective reasons.
- Safety1stClyde 10y ago
  > There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today Someone called Kristaps Dzonsons wrote a manual page renderer and a cgi/fastcgi library in C quite recently.
- pjmlp 10y ago
  ESPOL and a full OS written in it, Burroughs B5500 nowadays sold as Unisys MCP, predates C by about 10 years, having been released in 1961. There were already powerful computers than the PDP-11, with more saner languages.
LambdaComplex 10y ago
> Following the logic here, you seem to be implying that no-one except the irresponsible should use C. There are some platforms (such as embedded systems) where C really is the only choice. But if you do have a choice? Then I don't think using C is a good idea. I'm not sure if "irresponsible" is the right word, though. I think developers underestimate the risks of C's unsafety and/or overestimate their ability to properly deal with it. Hanlon's razor[0] applies. 0. https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor
- nickpsecurity 10y ago
  "There are some platforms (such as embedded systems) where C really is the only choice. " That's never true. You can always use a higher-level, safer language that can compile to C. The result is C code but you never write it & avoid its pitfalls. Ivory language in Haskell, Ada-to-C, and Modula-2-to-C come to mind. Alternatively, you can use something even more primitive in a C subset or native assembly that it compiles to. OcaPIC or JavaCard come to mind. Astrobe Oberon is another for safe, low-level coding but not sure how its compiler works.
  - adrianN 10y ago
    Adding an extra compilation step doesn't make debugging easier. The embedded C compilers also aren't known for their stability and standards compliance, so you'd likely have to massage your generated C to avoid bugs in the C compiler.
    - nickpsecurity 10y ago
      Those are good points worth considering for a given tool.
- sametmax 10y ago
  No you can write rust now.
  - 10y ago

geofft 10y ago

> Following the logic here, you seem to be implying that no-one except the irresponsible should use C. This seems highly likely, yes. C was a good language at the time. It's still probably a very good teaching language for systems programming. But it's a bad language for anyone who wants to write software that needs to be used responsibly. It predates the entire idea that some people on the network might be hostile. It predates the knowledge that buffer overflows might be used for malice. It predates about 40 years of programming language research and security research, some of which has even shown results. C also predates computers of modern speed; it was written at a time when interpreted languages were mostly unthinkable for serious software. There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today, but it was presumably the best tool for the job at the time. It is no criticism of C to say that it has served us well but it is a bad choice for new software for clear and objective reasons.

Safety1stClyde 10y ago
> There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today Someone called Kristaps Dzonsons wrote a manual page renderer and a cgi/fastcgi library in C quite recently.
pjmlp 10y ago
ESPOL and a full OS written in it, Burroughs B5500 nowadays sold as Unisys MCP, predates C by about 10 years, having been released in 1961. There were already powerful computers than the PDP-11, with more saner languages.

LambdaComplex 10y ago

> Following the logic here, you seem to be implying that no-one except the irresponsible should use C. There are some platforms (such as embedded systems) where C really is the only choice. But if you do have a choice? Then I don't think using C is a good idea. I'm not sure if "irresponsible" is the right word, though. I think developers underestimate the risks of C's unsafety and/or overestimate their ability to properly deal with it. Hanlon's razor[0] applies. 0. https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor

nickpsecurity 10y ago
"There are some platforms (such as embedded systems) where C really is the only choice. " That's never true. You can always use a higher-level, safer language that can compile to C. The result is C code but you never write it & avoid its pitfalls. Ivory language in Haskell, Ada-to-C, and Modula-2-to-C come to mind. Alternatively, you can use something even more primitive in a C subset or native assembly that it compiles to. OcaPIC or JavaCard come to mind. Astrobe Oberon is another for safe, low-level coding but not sure how its compiler works.
- adrianN 10y ago
  Adding an extra compilation step doesn't make debugging easier. The embedded C compilers also aren't known for their stability and standards compliance, so you'd likely have to massage your generated C to avoid bugs in the C compiler.
  - nickpsecurity 10y ago
    Those are good points worth considering for a given tool.
sametmax 10y ago
No you can write rust now.
- 10y ago