4 ms·
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 mes
by 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 agoLoads 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 agoPeople 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.