5 ms·

Those error messages, no matter how good, are curing the symptom not the cause. In other languages this particular problem doesn't exist in the first place.

by jules 10y ago

Sir_Cmpwn 10y ago
Rust has not killed and will not kill C. Can we please cut this crap out? Rust is a cool and useful language but I am getting tired of its proponents talking smack about everything else all the time.
- dikaiosune 10y ago
  The person you're replying to didn't even mention Rust -- and they're right that many languages other than Rust avoid the problems cited in the listed error messages.
  - Sir_Cmpwn 10y ago
    Loads of languages have old functions that could be better with hindsight, I'd probably say all of them. Some of them even have security implications (mysql_real_escape, anyone?). C isn't going away any time soon, and there's no value in decrying it as a response to being told about a feature that makes it safer!
    - nickpsecurity 10y ago
      "Loads of languages have old functions that could be better with hindsight" Strawman. C's predecessors did it better with foresight. One of best such systems was built by C's inventors. BCPL author and C inventors deliberately removed safety at OS and language level due to hardware constraints plus personal preferences. Then nobody changed it to avoid work or broken apps. Hindsight aspect has nothing to do with it. "C isn't going away any time soon, and there's no value in decrying it as a response to being told about a feature that makes it safer!" Got mixed feelings on when to slam C or help its users out. I agree with you that bashing it at a comment on a safety improvement is probably a bad idea. It might have effect of reducing number of people promoting safer C strategies. I usually ignore, upvote them, or mention stuff like SAFEcode/Softbound depending on what's in comment. I go anti-C when misinformation shows up or on more general topics of safe, efficient apps.
      - MaulingMonkey 10y ago
        > Got mixed feelings on when to slam C or help its users out. All the same coin to me. Decry C, laud the tools that make it safer, and sympathize with the poor bastards stuck with it all in one breath. I C++ for a living - you may pity me too. Games, you know. > It might have effect of reducing number of people promoting safer C strategies. It might have the effect of increasing the number of people promoting safer programming strategies. Maybe not contributing to the depressing statistics on buffer overflow CVEs by writing their startup's entire serverside stack in vanilla memory-unsafe C. Why, they could even use some kind of LISP variant... (yes yes, here's some tinder, may any and all do with my strawman as they please...)
        nickpsecurity 10y ago
        " I C++ for a living - you may pity me too. Games, you know." I've had the displeasure of dealing with it myself. So, a little bit. It can give you a bit of extra safety and flexibility with acceptable performance. Side effect, as I noted for ZeroTier, is you forfeit almost all the static analysis, memory-safe compilers, and other goodies for C language. You're in the category that might benefit from experiments with Rust given it's the C++ competitor, but with more safety. Maybe those ridiculous bugs I see in AAA titles will go away without much extra QA. Nah, I'll be unlucky and they'll be algorithmic. ;) " Why, they could even use some kind of LISP variant..." That's so 90's. Next you're going to want them to try to round up all the hackers, programmers, and VC's on one discussion forum. Can't expect people to pull that kind of stuff off. Far as LISP, check out PreScheme: static LISP w/ manual, memory management and compiled to C at first. Got mathematically verified during VLISP project. Enhancement of that could do games or startups. (taps head) Actually, CARP Lisp is doing that with Rust-style safety if I recall. Has active contributors with an OpenGL snippet as demo: https://news.ycombinator.com/item?id=12039268 https://news.ycombinator.com/item?id=12039268
    - pjmlp 10y ago
      People apparently are slow learners: "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. " -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html So in 1979 it was already clear that C wasn't for the faint of heart, but it took until clang for developers to take static analysis in C seriously. And even today I hardly know of any enterprise project in companies we have access to, that cares about such tooling in C.
- tatterdemalion 10y ago
  Not only did the user you replied to not mention Rust, as far as I can tell they are not an active Rust user. The Rust community has a clear policy against language zealotry. Your claim that "proponents [of Rust] [are] talking smack about everything else all the time" wants for evidence.
  - Sir_Cmpwn 10y ago
    It's difficult to search for, since usually such comments end up in threads that aren't about Rust, criticizing the actual topic for not using Rust. I guess I'll have to write down whenever I see this for the next time someone complains about my complaint. I do have one link handy, since I participated in this thread myself: https://news.ycombinator.com/item?id=11620962 https://news.ycombinator.com/item?id=11620962
    - tatterdemalion 10y ago
      You're the person who brought up Rust in that thread. The user 'mokus', which is a handle I do not recognize from the Rust community, advocates using 'memory safe languages' over C. So apparently you have a habit of projecting support for Rust on anyone who criticizes C?
      - Sir_Cmpwn 10y ago
        This is very quickly devolving into a stupid flamewar, assuming it isn't already there. This is a thread about Rust error messages. When someone describes useful C warnings messages and someone follows up with criticism for C even making situations where those warnings are possible in such a thread, it's pretty reasonable to make the connection. What's your problem, dude?
        oldmanjay 10y ago
        I don't think the issue was that you made a connection to Rust. The issue seems to be that you used it as an excuse to rant about a tangent with an aggressive tone in article that will attract proponents of the target of your rant. In other words, it didn't devolve into a flamewar, because that's where you started it out.
- pjmlp 10y ago
  It doesn't need to be Rust, but until C keeps around, this list won't get smaller: http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corruption http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+c... 3795 and counting, every day something new!

Those error messages, no matter how good, are curing the symptom not the cause. In other languages this particular problem doesn't exist in the first place.

by jules 10y ago

Those error messages, no matter how good, are curing the symptom not the cause. In other languages this particular problem doesn't exist in the first place.

Sir_Cmpwn 10y ago

Rust has not killed and will not kill C. Can we please cut this crap out? Rust is a cool and useful language but I am getting tired of its proponents talking smack about everything else all the time.

dikaiosune 10y ago
The person you're replying to didn't even mention Rust -- and they're right that many languages other than Rust avoid the problems cited in the listed error messages.
- Sir_Cmpwn 10y ago
  Loads of languages have old functions that could be better with hindsight, I'd probably say all of them. Some of them even have security implications (mysql_real_escape, anyone?). C isn't going away any time soon, and there's no value in decrying it as a response to being told about a feature that makes it safer!
  - nickpsecurity 10y ago
    "Loads of languages have old functions that could be better with hindsight" Strawman. C's predecessors did it better with foresight. One of best such systems was built by C's inventors. BCPL author and C inventors deliberately removed safety at OS and language level due to hardware constraints plus personal preferences. Then nobody changed it to avoid work or broken apps. Hindsight aspect has nothing to do with it. "C isn't going away any time soon, and there's no value in decrying it as a response to being told about a feature that makes it safer!" Got mixed feelings on when to slam C or help its users out. I agree with you that bashing it at a comment on a safety improvement is probably a bad idea. It might have effect of reducing number of people promoting safer C strategies. I usually ignore, upvote them, or mention stuff like SAFEcode/Softbound depending on what's in comment. I go anti-C when misinformation shows up or on more general topics of safe, efficient apps.
    - MaulingMonkey 10y ago
      > Got mixed feelings on when to slam C or help its users out. All the same coin to me. Decry C, laud the tools that make it safer, and sympathize with the poor bastards stuck with it all in one breath. I C++ for a living - you may pity me too. Games, you know. > It might have effect of reducing number of people promoting safer C strategies. It might have the effect of increasing the number of people promoting safer programming strategies. Maybe not contributing to the depressing statistics on buffer overflow CVEs by writing their startup's entire serverside stack in vanilla memory-unsafe C. Why, they could even use some kind of LISP variant... (yes yes, here's some tinder, may any and all do with my strawman as they please...)
      - nickpsecurity 10y ago
        " I C++ for a living - you may pity me too. Games, you know." I've had the displeasure of dealing with it myself. So, a little bit. It can give you a bit of extra safety and flexibility with acceptable performance. Side effect, as I noted for ZeroTier, is you forfeit almost all the static analysis, memory-safe compilers, and other goodies for C language. You're in the category that might benefit from experiments with Rust given it's the C++ competitor, but with more safety. Maybe those ridiculous bugs I see in AAA titles will go away without much extra QA. Nah, I'll be unlucky and they'll be algorithmic. ;) " Why, they could even use some kind of LISP variant..." That's so 90's. Next you're going to want them to try to round up all the hackers, programmers, and VC's on one discussion forum. Can't expect people to pull that kind of stuff off. Far as LISP, check out PreScheme: static LISP w/ manual, memory management and compiled to C at first. Got mathematically verified during VLISP project. Enhancement of that could do games or startups. (taps head) Actually, CARP Lisp is doing that with Rust-style safety if I recall. Has active contributors with an OpenGL snippet as demo: https://news.ycombinator.com/item?id=12039268 https://news.ycombinator.com/item?id=12039268
  - pjmlp 10y ago
    People apparently are slow learners: "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. " -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html So in 1979 it was already clear that C wasn't for the faint of heart, but it took until clang for developers to take static analysis in C seriously. And even today I hardly know of any enterprise project in companies we have access to, that cares about such tooling in C.
tatterdemalion 10y ago
Not only did the user you replied to not mention Rust, as far as I can tell they are not an active Rust user. The Rust community has a clear policy against language zealotry. Your claim that "proponents [of Rust] [are] talking smack about everything else all the time" wants for evidence.
- Sir_Cmpwn 10y ago
  It's difficult to search for, since usually such comments end up in threads that aren't about Rust, criticizing the actual topic for not using Rust. I guess I'll have to write down whenever I see this for the next time someone complains about my complaint. I do have one link handy, since I participated in this thread myself: https://news.ycombinator.com/item?id=11620962 https://news.ycombinator.com/item?id=11620962
  - tatterdemalion 10y ago
    You're the person who brought up Rust in that thread. The user 'mokus', which is a handle I do not recognize from the Rust community, advocates using 'memory safe languages' over C. So apparently you have a habit of projecting support for Rust on anyone who criticizes C?
    - Sir_Cmpwn 10y ago
      This is very quickly devolving into a stupid flamewar, assuming it isn't already there. This is a thread about Rust error messages. When someone describes useful C warnings messages and someone follows up with criticism for C even making situations where those warnings are possible in such a thread, it's pretty reasonable to make the connection. What's your problem, dude?
      - oldmanjay 10y ago
        I don't think the issue was that you made a connection to Rust. The issue seems to be that you used it as an excuse to rant about a tangent with an aggressive tone in article that will attract proponents of the target of your rant. In other words, it didn't devolve into a flamewar, because that's where you started it out.
pjmlp 10y ago
It doesn't need to be Rust, but until C keeps around, this list won't get smaller: http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corruption http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+c... 3795 and counting, every day something new!