6 ms·

That's an easily correctable problem: learn the living daylights out of programming in assembler, and then C will be like a walk in the park: no more overflows,

by Annatar 10y ago

That's an easily correctable problem: learn the living daylights out of programming in assembler, and then C will be like a walk in the park: no more overflows, no more pointer screwups, no more forgetting to free the memory, because you'll know exactly what will happen in the chip and the memory when that code compiles. You'll even start writing code which relies on integer overflow (rollover from #$ff to #$00 again) because, depending on the situation, it will give you a performance boost, or make the algorithm implementation simpler, or both, and you'll know it. It's long past time to invent and use better systems languages. I can't comment on Go, but the textbook examples of Rust and even treatises on the subject from recognized experts in the computer science field (Adam Leventhal) show it to be an utterly overcomplicated language for which there should be a criminal trial and a prison sentence of several decades. Immutables, borrowing, no, I have to stop; my head hurts already, and I'm getting a migraine thinking about solving even the simplest of classic input-output problems with such an overly complicated language. (And my head wants to explode when I compare Rust with AWK for solving input/output problems, the biggest reason why computers were invented.) So... C, C, and more C, because it's infinitely flexible and simple. I like simple, because simple is smart. Complicated and complex isn't. Let's all please be humane to one another and stop inventing more languages. We need less languages, not a bazillion variations on the one central task: making the computer do something. And for that, we already have all the languages we could ever want or need, and for the theoretical case where we don't, there is always the almighty assembler, in which exist no limitations as to what one can program with it.

pka 10y ago
At first I thought that was sarcasm... but it's unfortunately not. > no more overflows, no more pointer screwups, no more forgetting to free the memory, because you'll know exactly what will happen in the chip and the memory when that code compiles To whoever wrote this: are you ready to share the code of a sufficiently complex program in C (or assembler, why not) you wrote and pay $100 for every "pointer screwup", buffer overflow, memory leak and generally every bug people find, which could have been prevented by a strong type system or borrow checking and other such complicated features?
- pjmlp 10y ago
  $1 would be enough, you could still get rich.
ekidd 10y ago
That's an easily correctable problem: learn the living daylights out of programming in assembler, and then C will be like a walk in the park: no more overflows, no more pointer screwups, no more forgetting to free the memory, because you'll know exactly what will happen in the chip and the memory when that code compiles. Knowing how processors work doesn't prevent people from making mistakes. I knew assembly long before I knew C, because I grew up on computers that were too small to run a C compiler. I've contributed to a half-dozen compilers. I've written disassemblers for weird embedded DSP chips. And by the standards of C programmers, I'm pretty paranoid. None of this makes me superhuman. I make mistakes. I've written network-facing C code, and I've left people exposed to security holes. Want to see the carnage? https://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-c.html https://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc... That's 6 CVEs against an obscure C networking library that I wrote. Technically, none of them were found in my code (not yet). All were in the third-party XML parser that I chose to use. But that doesn't absolve me of fault, and I bet there's a few more bugs lurking in my code that could be found with modern fuzzers. I don't care whether people use Go or Swift or D or Rust or some brand new language. But wherever C goes, bugs and security holes almost inevitably follow. It's going to take decades to reduce the proportion of C in our systems, and we ought to start now.
- Annatar 10y ago
  That's 6 CVEs against an obscure C networking library that I wrote. Technically, none of them were found in my code (not yet). All were in the third-party XML parser that I chose to use. But that doesn't absolve me of fault, and I bet there's a few more bugs lurking in my code that could be found with modern fuzzers. While it is commendable that you take responsibility, you mis-diagnosed your error: it isn't the C programming language, but what you chose to do with it: send/receive extensible markup language for remote procedure calls. Seems like a great idea, until you actually have to deal with it. I just happen to be working on an application where I'm forced to generate XML-SOAP and send that over the network to a server, and then process the XML-SOAP response I get back with XPATH, using xsltproc. And all that because the designers of the server application use Java and didn't even know they were using XML-SOAP and XPATH, since by the time they work with it, Java libraries treat them as objects. (And neither did I, until I reverse-engineered the responses I'm getting.) I have caused the server to crash innumerable amount of times. You're arguing for better systems languages, and I'm telling you that is a terrible idea because we have nobody so smart as to design something so complex to be simple, and the closest we have ever come to it is C. We already have way too many languages, that it's become a nauseating torture to work with computers.
pjc50 10y ago
> because you'll know exactly what will happen in the chip and the memory when that code compiles. .. for the specific chip you've targeted. And possibly even the specific stepping. And that's assuming that you're diligent enough to manually review all that assembler. Very, very few people are. This is why typesafe code was developed. This is why all those checks exist in Rust. Limitations are good. Limitations are your safety equipment. Assembler is the guy who scrambles up on the roof without tether or hardhat to "get the job done". > language for which there should be a criminal trial and a prison sentence of several decades Commentators who overuse hyperbole should be executed.
- Annatar 10y ago
  Commentators who overuse hyperbole should be executed. It's not a hyperbole: if I could, I would make it into a criminal offense which carried at least a 20 years prison sentence with it, so that next time, anyone who came up with an idea of writing yet another systems language would think really long and hard about how to make that language really simple. The prison sentence would serve as a deterrent, so that only people who really knew what they were doing would attempt to tackle the problem. I feel that strongly about it. I'm already in favor of making information technology into a licensed profession with rigorous state and/or bar examinations, as is the case with medical doctors and lawyers. This is after 30+ years of debugging and fixing other people's code.
  - deleted 10y ago
    [deleted]
pjmlp 10y ago
C doesn't offer anything better over Algol based systems programming languages, other that easier ways to corrupt data and ability to program write-only code.
pcwalton 10y ago
> I can't comment on Go, but the textbook examples of Rust and even treatises on the subject from recognized experts in the computer science field (Adam Leventhal) show it to be an utterly overcomplicated language for which there should be a criminal trial and a prison sentence of several decades. You sure are angry with me for working on a programming language.
- sanderjd 10y ago
  Yeah I don't get this sort of attitude at all. It seems like a very simple sequence of steps: 1. Creating something non-trivial in language X, 2. Identifying things that language X made difficult, 3. Brainstorming ways to implement solutions to those issues within a set of acceptable trade-offs, 4. Concluding that some of the brainstormed ideas might actually work, 5. Working really hard to implement and iterate on them. I can't figure out which step the parent commenter scorns. I guess probably step 2, where they see no pain points to begin with. That's fine, but trying to convince people they haven't felt pain that they have felt is a silly battle. I guess they're actually implying that people who have felt that pain are just not smart enough.
  - Annatar 10y ago
    No, I'm implying that people are either too egotistical or that they overestimate their insights, or both, when they create a new language. These days it seems like there is a new language every 15 minutes. It's getting to be ridiculous. And the worst part of it is, no such language covers all problems effectively; they all have flaws in one way or another... so the next guy comes along thinking he can do it better, and just repeats the mistake of his or her predecessor(s). Instead of realizing that this would just exacerbate the problem, they go ahead and make it worse. I guess they're actually implying that people who have felt that pain are just not smart enough. It is extremely difficult to solve a complex problem in a simple manner. One literally has to be a genius with a lifetime of experience and insights from that experience in order to be able to pull that off, and even then, it doesn't always work and requires multiple iterations, and lots and lots of experimentation. Case in point: Go, still a work in progress by exactly such people. That should be instructive, but it seems that it isn't.
moosingin3space 10y ago
> I can't comment on Go, but the textbook examples of Rust and even treatises on the subject from recognized experts in the computer science field (Adam Leventhal) show it to be an utterly overcomplicated language for which there should be a criminal trial and a prison sentence of several decades. Immutables, borrowing, no, I have to stop; my head hurts already, and I'm getting a migraine thinking about solving even the simplest of classic input-output problems with such an overly complicated language. (And my head wants to explode when I compare Rust with AWK for solving input/output problems, the biggest reason why computers were invented.) The level of contempt for other people and utter lack of perspective shown by this comment makes my head want to explode.
na85 10y ago
>because you'll know exactly what will happen in the chip and the memory when that code compiles. No you won't. Assembly is an abstraction now, at least on x86. The chip does all sorts of things in ucode behind the scenes
abecedarius 10y ago
You say that knowing assembler makes it easy to understand how incorrect C code behaves. This was sort of true a few decades ago, when I learned C after learning assembler. It stopped being true around 15 years ago when the popular compilers started interpreting the C standard like your ex-wife's divorce lawyer (as Kragen put it). I used to write a lot of C, and I no longer use it for anything serious either, because I'm too stupid and the stakes are higher. Maybe better tool support could change that, but I'd prefer a better language.
Blaisorblade0 10y ago
Knowing assembly won't teach you the difference between legal overflows and ones triggering undefined behavior, or why you might need -fno-strict-aliasing to cast your pointers, and many more things. Does anybody know any correct nontrivial C programs beyond the ones by DJB? Or anything close? And it's not like, once bug-free, those are evolving much...

by Annatar 10y ago

pka 10y ago

At first I thought that was sarcasm... but it's unfortunately not. > no more overflows, no more pointer screwups, no more forgetting to free the memory, because you'll know exactly what will happen in the chip and the memory when that code compiles To whoever wrote this: are you ready to share the code of a sufficiently complex program in C (or assembler, why not) you wrote and pay $100 for every "pointer screwup", buffer overflow, memory leak and generally every bug people find, which could have been prevented by a strong type system or borrow checking and other such complicated features?

pjmlp 10y ago
$1 would be enough, you could still get rich.

ekidd 10y ago

That's an easily correctable problem: learn the living daylights out of programming in assembler, and then C will be like a walk in the park: no more overflows, no more pointer screwups, no more forgetting to free the memory, because you'll know exactly what will happen in the chip and the memory when that code compiles. Knowing how processors work doesn't prevent people from making mistakes. I knew assembly long before I knew C, because I grew up on computers that were too small to run a C compiler. I've contributed to a half-dozen compilers. I've written disassemblers for weird embedded DSP chips. And by the standards of C programmers, I'm pretty paranoid. None of this makes me superhuman. I make mistakes. I've written network-facing C code, and I've left people exposed to security holes. Want to see the carnage? https://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-c.html https://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc... That's 6 CVEs against an obscure C networking library that I wrote. Technically, none of them were found in my code (not yet). All were in the third-party XML parser that I chose to use. But that doesn't absolve me of fault, and I bet there's a few more bugs lurking in my code that could be found with modern fuzzers. I don't care whether people use Go or Swift or D or Rust or some brand new language. But wherever C goes, bugs and security holes almost inevitably follow. It's going to take decades to reduce the proportion of C in our systems, and we ought to start now.

Annatar 10y ago
That's 6 CVEs against an obscure C networking library that I wrote. Technically, none of them were found in my code (not yet). All were in the third-party XML parser that I chose to use. But that doesn't absolve me of fault, and I bet there's a few more bugs lurking in my code that could be found with modern fuzzers. While it is commendable that you take responsibility, you mis-diagnosed your error: it isn't the C programming language, but what you chose to do with it: send/receive extensible markup language for remote procedure calls. Seems like a great idea, until you actually have to deal with it. I just happen to be working on an application where I'm forced to generate XML-SOAP and send that over the network to a server, and then process the XML-SOAP response I get back with XPATH, using xsltproc. And all that because the designers of the server application use Java and didn't even know they were using XML-SOAP and XPATH, since by the time they work with it, Java libraries treat them as objects. (And neither did I, until I reverse-engineered the responses I'm getting.) I have caused the server to crash innumerable amount of times. You're arguing for better systems languages, and I'm telling you that is a terrible idea because we have nobody so smart as to design something so complex to be simple, and the closest we have ever come to it is C. We already have way too many languages, that it's become a nauseating torture to work with computers.

pjc50 10y ago

> because you'll know exactly what will happen in the chip and the memory when that code compiles. .. for the specific chip you've targeted. And possibly even the specific stepping. And that's assuming that you're diligent enough to manually review all that assembler. Very, very few people are. This is why typesafe code was developed. This is why all those checks exist in Rust. Limitations are good. Limitations are your safety equipment. Assembler is the guy who scrambles up on the roof without tether or hardhat to "get the job done". > language for which there should be a criminal trial and a prison sentence of several decades Commentators who overuse hyperbole should be executed.

Annatar 10y ago
Commentators who overuse hyperbole should be executed. It's not a hyperbole: if I could, I would make it into a criminal offense which carried at least a 20 years prison sentence with it, so that next time, anyone who came up with an idea of writing yet another systems language would think really long and hard about how to make that language really simple. The prison sentence would serve as a deterrent, so that only people who really knew what they were doing would attempt to tackle the problem. I feel that strongly about it. I'm already in favor of making information technology into a licensed profession with rigorous state and/or bar examinations, as is the case with medical doctors and lawyers. This is after 30+ years of debugging and fixing other people's code.
- deleted 10y ago
  [deleted]

pjmlp 10y ago

C doesn't offer anything better over Algol based systems programming languages, other that easier ways to corrupt data and ability to program write-only code.

pcwalton 10y ago

sanderjd 10y ago
Yeah I don't get this sort of attitude at all. It seems like a very simple sequence of steps: 1. Creating something non-trivial in language X, 2. Identifying things that language X made difficult, 3. Brainstorming ways to implement solutions to those issues within a set of acceptable trade-offs, 4. Concluding that some of the brainstormed ideas might actually work, 5. Working really hard to implement and iterate on them. I can't figure out which step the parent commenter scorns. I guess probably step 2, where they see no pain points to begin with. That's fine, but trying to convince people they haven't felt pain that they have felt is a silly battle. I guess they're actually implying that people who have felt that pain are just not smart enough.
- Annatar 10y ago
  No, I'm implying that people are either too egotistical or that they overestimate their insights, or both, when they create a new language. These days it seems like there is a new language every 15 minutes. It's getting to be ridiculous. And the worst part of it is, no such language covers all problems effectively; they all have flaws in one way or another... so the next guy comes along thinking he can do it better, and just repeats the mistake of his or her predecessor(s). Instead of realizing that this would just exacerbate the problem, they go ahead and make it worse. I guess they're actually implying that people who have felt that pain are just not smart enough. It is extremely difficult to solve a complex problem in a simple manner. One literally has to be a genius with a lifetime of experience and insights from that experience in order to be able to pull that off, and even then, it doesn't always work and requires multiple iterations, and lots and lots of experimentation. Case in point: Go, still a work in progress by exactly such people. That should be instructive, but it seems that it isn't.

moosingin3space 10y ago

> I can't comment on Go, but the textbook examples of Rust and even treatises on the subject from recognized experts in the computer science field (Adam Leventhal) show it to be an utterly overcomplicated language for which there should be a criminal trial and a prison sentence of several decades. Immutables, borrowing, no, I have to stop; my head hurts already, and I'm getting a migraine thinking about solving even the simplest of classic input-output problems with such an overly complicated language. (And my head wants to explode when I compare Rust with AWK for solving input/output problems, the biggest reason why computers were invented.) The level of contempt for other people and utter lack of perspective shown by this comment makes my head want to explode.

na85 10y ago

>because you'll know exactly what will happen in the chip and the memory when that code compiles. No you won't. Assembly is an abstraction now, at least on x86. The chip does all sorts of things in ucode behind the scenes

abecedarius 10y ago

You say that knowing assembler makes it easy to understand how incorrect C code behaves. This was sort of true a few decades ago, when I learned C after learning assembler. It stopped being true around 15 years ago when the popular compilers started interpreting the C standard like your ex-wife's divorce lawyer (as Kragen put it). I used to write a lot of C, and I no longer use it for anything serious either, because I'm too stupid and the stakes are higher. Maybe better tool support could change that, but I'd prefer a better language.

Blaisorblade0 10y ago

Knowing assembly won't teach you the difference between legal overflows and ones triggering undefined behavior, or why you might need -fno-strict-aliasing to cast your pointers, and many more things. Does anybody know any correct nontrivial C programs beyond the ones by DJB? Or anything close? And it's not like, once bug-free, those are evolving much...