Linked by MOS6510 on Thu 10th Jan 2013 23:25 UTC
General Development "For years I've tried my damnedest to get away from C. Too simple, too many details to manage, too old and crufty, too low level. I've had intense and torrid love affairs with Java, C++, and Erlang. I've built things I'm proud of with all of them, and yet each has broken my heart. They've made promises they couldn't keep, created cultures that focus on the wrong things, and made devastating tradeoffs that eventually make you suffer painfully. And I keep crawling back to C."
Permalink for comment 548362
To read all comments associated with this story, please click here.
RE: C == Security Exploits by design
by saso on Fri 11th Jan 2013 12:13 UTC in reply to "C == Security Exploits by design"
saso
Member since:
2007-04-18

At the time C was developed, even during the 80's, there were languages which had better compilation speeds like Turbo Pascal and Modula-2.

Oh cry me a river.

The UNIX guys also decided to ignore the languages of their time, which provided already better type checking than C does.

And there is no way you could possibly be wrong about that!

no modules

Sure it has them, though presuming you didn't know about them, you have no idea what "static" on globals and functions means.

no way to namespace identifiers besides 70's like hacks

Namespaces are a mixed bag. Sometimes they might seem useful, but more often than not I've seen them abused and make simple problems a lot more complex. Also, they are a nightmare to debug, especially when combining code from various sources (e.g. library linking) - name mangling is a linker's nightmare. It seems that huge projects, like the Linux kernel for instance, seem to work just fine without them.

null terminated strings are a open door to security exploits
the way arrays decay into pointers ditto

I think you're more complaining about a lack of automatic range checking. Sometimes it's useful, sometimes it isn't (mainly by introducing invisible glue code that can mess up some assumptions, e.g. atomicity).

weak type checking

Compared to what? For my tastes the type checking in C is pretty strong.

pointer aliasing forbids certain types of optimizations

"restrict" has been in C since 1999. Your complaint is 13 years out of date.

Read MISRA C

They ask for money, no thanks. (NASA coding guidelines are an interesting read though.)

Enable all warnings as errors

Not all warnings are errors and while it helps in development, it's very bad for e.g. libraries to ship code with -Werror enabled, since a change in compiler versions can introduce new/different checks or obsolete build options and thus make break your build.

Use static analyzers as part of the build process

lint has been in Unix since V7 (1979).

Funny enough with those steps C gets to be almost as safe as the Pascal family of languages.

Something stinks with the notable stench of "smug".

[Objective-C, C++] do offer more secure language constructs, but they are undermined by the C constructs they also support.

It is true that C gives you greater freedom in certain things and that includes shooting yourself in the foot. No question about it. On the other hand, certain things are much easier and better done in C (low-level data crunching routines).

Even Ritchie did recognize that C has a few issues:
http://cm.bell-labs.com/who/dmr/chist.html

And there he claims, among other things, that C type specifications are richer than Pascal's, directly contradicting your earlier statement. Be careful who you cite to support your case.

If UNIX did not get copied in all universities all over the world in the early 80's, C would just be another language in history books.

Looks like somebody's got an axe to grind.

Reply Parent Score: 1