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."
Thread beginning with comment 548326
To read all comments associated with this story, please click here.
C == Security Exploits by design
by moondevil on Fri 11th Jan 2013 08:12 UTC
moondevil
Member since:
2005-07-08

The author is no doubt enthusiastic about C, but there are quite a few things he gets wrong.

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.

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

C main weakness:

- no modules
- no way to namespace identifiers besides 70's like hacks
- null terminated strings are a open door to security exploits
- the way arrays decay into pointers ditto
- weak type checking
- pointer aliasing forbids certain types of optimizations

C developers used to complain about Pascal type safety in the 80, but if you security conscious:

- Read MISRA C
- Enable all warnings as errors
- Use static analyzers as part of the build process

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

C needs to get replaced for us to get better security, as well as its Objective-C and C++ descendants.

The latter do offer more secure language constructs, but they are undermined by the C constructs they also support.

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

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.

Reply Score: 4

renox Member since:
2005-07-06

There are more weaknesses: very poor standard library which doesn't even contain a hash map or safe string handling..

Reply Parent Score: 6

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

moondevil Member since:
2005-07-08

"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!
"

Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?


"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.
"

It is has not.

Separate compilation is a primitive form of modules, but it is not the same.


"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.
"

Sure we could also keep on using the original UNIX, why care about progress?


"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).
"

Forget about the NULL character, boom!

Arrays should not be manipulated as pointers.

As for the usual C argument about arrays bound checking, all modern languages that compile to native code allow for selective disable of bounds checking if required.

"weak type checking

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

Almost every other static type language out there?


"pointer aliasing forbids certain types of optimizations

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

Except, like register, the compiler is free to ignore it and besides gcc and clang many C vendors still don't fully implement C99.

"Read MISRA C

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

In our society people tend to get money for their work.

"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.
"

You can always turn off false positives.

"Use static analyzers as part of the build process

lint has been in Unix since V7 (1979).
"

Sure, but:

- UNIX is just one OS among many
- Being available does not mean developers use it

"[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).
"

Like in many other languages.

"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.
"

Sure, when compared with the original ISO Pascal. The ISO Extended Pascal as any other Pascal dialects are more expressive than C.

"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.
"

UNIX is a good operating system, but it is not the god of operating systems.

Reply Parent Score: 5