4 ms·

Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don

Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don't expect good results. If you have to write 'C', learn 'C'. I'd say the same of C++, but by the time you learn it, it's become something different :)

pcwalton 11y ago
> Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don't expect good results. OK, but the fact remains that undefined behavior due to bounds checks is orders of magnitude less frequent in, say, Ruby than in C. I have a hard time seeing this as anything other than a good result.
- ArkyBeagle 11y ago
  I can't argue with that at all. I'm just saying if you're stuck using 'C', it's worth learning the strategies and habits needed to prevent unsafe code. There are issues other than safety that influence these decisions. Rust & Lua are also closer to 'C' than is Ruby, so ....
klodolph 11y ago
Array bounds errors are a common source of problems in C. Fixing these errors with behavioral changes is expensive. It increases the amount of training and increases the cognitive load on programmers, and yet errors will still slip by because we are imperfect. On the other hand, if I add bounds checking to my programming language, then I've just transformed serious vulnerabilities into simple runtime errors. Computers are easier to reprogram than brains are.
- sangnoir 11y ago
  How about "taking heed of compiler warnings" as suggested by Linus? it's niether expensive nor mentally taxing
  - nickpsecurity 11y ago
    How about eliminating the need for them in the common case like other systems languages did? Why should you have to worry every time you do a common operation if the alternative has acceptable performance and is actually more productive? And I'll add that most of the older, safe languages let you turn off safety for performance if you have to. You just then have to use you brain like you would with C or whatever. Just for that module, though, along with calls into it.
- ArkyBeagle 11y ago
  Which costs more, the errors or the behavioral changes?
- ArkyBeagle 11y ago
  Within ... months(2? 3?) of starting learning 'C'. I no longer produced code that was capable of array bounds violations. Of course you slip up now and again, but it's just a matter of habits. This was in 1987 or so. Perhaps that was unusual; I don't know. It was part of the culture where I worked. I'd programmed professionally in Pascal before, so I'm familiar wit the compare/contrast here. Tactically, it was safer, because 'C' covered more than did Pascal, and the balance of the code when you used pascal was assembly. Perhaps the assembly was sufficiently dangerous that we didn't make as many mistakes, so who knows? We felt assembler was more of a liability. The choices were more limited then. Performance, shmerformance - darn near everything runs fast enough, now, with the exception of a few grotty corners. Rust/Python/what have you are all very nice. I just sympathize with the poor people who get drafted into working on 'C' code bases without seeming to be happy about it. I personally would find somebody to mentor me a bit and review the code if I were in those shoes. Perhaps that sort of thing has passed; shame if it has.

pcwalton 11y ago

> Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don't expect good results. OK, but the fact remains that undefined behavior due to bounds checks is orders of magnitude less frequent in, say, Ruby than in C. I have a hard time seeing this as anything other than a good result.

ArkyBeagle 11y ago
I can't argue with that at all. I'm just saying if you're stuck using 'C', it's worth learning the strategies and habits needed to prevent unsafe code. There are issues other than safety that influence these decisions. Rust & Lua are also closer to 'C' than is Ruby, so ....

klodolph 11y ago

Array bounds errors are a common source of problems in C. Fixing these errors with behavioral changes is expensive. It increases the amount of training and increases the cognitive load on programmers, and yet errors will still slip by because we are imperfect. On the other hand, if I add bounds checking to my programming language, then I've just transformed serious vulnerabilities into simple runtime errors. Computers are easier to reprogram than brains are.

sangnoir 11y ago
How about "taking heed of compiler warnings" as suggested by Linus? it's niether expensive nor mentally taxing
- nickpsecurity 11y ago
  How about eliminating the need for them in the common case like other systems languages did? Why should you have to worry every time you do a common operation if the alternative has acceptable performance and is actually more productive? And I'll add that most of the older, safe languages let you turn off safety for performance if you have to. You just then have to use you brain like you would with C or whatever. Just for that module, though, along with calls into it.
ArkyBeagle 11y ago
Which costs more, the errors or the behavioral changes?
ArkyBeagle 11y ago
Within ... months(2? 3?) of starting learning 'C'. I no longer produced code that was capable of array bounds violations. Of course you slip up now and again, but it's just a matter of habits. This was in 1987 or so. Perhaps that was unusual; I don't know. It was part of the culture where I worked. I'd programmed professionally in Pascal before, so I'm familiar wit the compare/contrast here. Tactically, it was safer, because 'C' covered more than did Pascal, and the balance of the code when you used pascal was assembly. Perhaps the assembly was sufficiently dangerous that we didn't make as many mistakes, so who knows? We felt assembler was more of a liability. The choices were more limited then. Performance, shmerformance - darn near everything runs fast enough, now, with the exception of a few grotty corners. Rust/Python/what have you are all very nice. I just sympathize with the poor people who get drafted into working on 'C' code bases without seeming to be happy about it. I personally would find somebody to mentor me a bit and review the code if I were in those shoes. Perhaps that sort of thing has passed; shame if it has.