>C has a very weak type system and very weak runtime guarantees, making it much easier to introduce problems with no indication that something's up.
Here's an interesting example I've stumbled upon a few weeks ago:
https://stackoverflow.com/questions/31037149/type-safety-for...
float _Complex -> float doesn't require any diagnostic even though the imaginary component is (silently) discarded. Clang has one (not enabled by default or -Wall/-Wextra) however current GCC versions haven't.
I'm sure both people using C99 support for complex numbers are really bothered by this.
Re:Re: C as used/implemented in practice
by stephencanon on Tuesday July 14, 2015 @07:04AM
(#9883971)
Nope, never been a problem. Can't speak for the other guy.
Never been a problem for me either.
I think you're discounting the fact that the software with the bugs was written in C precisely because C was a better fit than the other languages which offered greater protection.
I'm not saying (and have never said) that C is better than other languages for every problem. I'm just saying that I read too many articles about the "problems" with C that Stupid C Programmers must not realize since we keep using it where the author of the article hasn't bothered to understand why programs are written in C in the first place.
So, yes, it is C's "fault" that it doesn't protect against classes of bugs that many other languages do. Sure, those languages have some of the same bugs that C does, but they're missing most of the very worst ones and that's really powerful. For example, a garbage collector protects against accessing dangling pointers: it's just not something the programmer has to worry about at all.
Rejecting cricitisms of C's safety inadequacies with "just code better"/"just learn the language better" doesn't work in practice: there have been too many high-profile vulnerabilities in C software, many of which would've been much harder to trigger in other languages.