Who Says C is Simple?

http://www.cs.berkeley.edu/~necula/cil/cil016.html

by ColinWright • 13 years ago

175 75 13 years ago

cs.berkeley.edu

joshuaellinger3• 13 years ago

Simple Language != Simple to use.

C is a small language. C is gussied-up assembly. It is the ballet of programming language.

People who say C is simple really mean that it doesn't do anything behind my back.

astine• 13 years ago

C is like the marketing slogan to Othello (reversi):

    A minute to learn, a lifetime to master.

The language is fairly simple in terms of features and aspects you have to learn to use it, but concepts like pointers and direct memory management are difficult to master. Programming in C is like building a building out of bricks; bricks are relatively simple objects, building a building out of them is not a simple task.

JonFish85• 13 years ago

Agree with both parents. "Simple" to me means that the code does exactly what I ask: no more, no less. For better or for worse. No behind-the-scenes magic (garbage collection, etc). I know exactly how much memory I am using, where it's allocated, and how it's passed around. Again, for better or for worse. With great power comes great responsibility!

venomsnake• 13 years ago

I think that pointers are hard is self fulfilling prophecy. We studied them in the 9th grade. Because nobody bothered to tell us they were hard almost my whole class - around 80% after the first two lessons groked pointers and linked lists.

Same was with pointer arithmetic and function pointers.

Right now I am struggling mightily with monads mostly because the voice in my head tells me the thing all of the internet is singing - they are hard don't bother.

Genmutant• 13 years ago

Also the standard library is really small. So after a short amount of time you have used almost all of it a few times.

PySlice• 13 years ago

However it's going to take some time to learn all the gotchas in string functions... Failing to zero-terminate strings (strncpy), potential buffer overflows (many), global internal buffer and overwriting an argument (strtok), etc etc etc etc

tel• 13 years ago

It "doesn't do anything behind my back" is exactly the phrase I've been searching for.

pcwalton• 13 years ago

But the article contains many examples of the compiler doing things behind your back. For example:

The answer depends on whether the optimizations are turned on. If they are then the answer is 3 (the first definition is inlined at all occurrences until the second definition). If the optimizations are off, then the first definition is ignore (treated like a prototype) and the answer is 4.

dietrichepp• 13 years ago

In that case, it's your fault for defining two versions of a function (inline and non-inline) that do different things.

anon13854• 13 years ago

Is it a small language? The standard takes a dense 179 pages to describe the language. I guess it's debatable if that is small or not. I certainly don't agree that it's a simple language though. There are myriad rules and exceptions to rules to remember. When and where one integer type will be converted to another. When overflow is defined and when it's undefined. Just those things alone mean that much real world C code is full of undefined behaviour[1] just related to arithmetic on numeric types, because the rules are hard to remember and reason about.

John Regehr asked people to submit str2long() implementations that didn't execute undefined behaviour. Despite being well warned about avoiding overflows and other undefined behaviour only 35 of the 78 submissions passed the test suite[2].

Even a trivially small 2 line C function can result in different results on the common compilers depending on which compiler and which optimisation level you use[3]. Compiler engineers struggle to agree on and correctly implement the "simple" rules of C. To me that's an indication that they aren't so simple.

I would say that C doesn't do anything behind your back as long as you don't ever use an optimising compiler or you pay very very close attention to the standard. If you forget then suddenly your check for pointer arithmetic overflow has been "helpfully optimised away" behind your back for reasons that are not immediately apparent at all[4].

I do agree that apparently simple rules can lead to complexity in use, and C is full of this too. For example you would think in a lower level language like C viewing a chunk of memory as a different type would be trivial, but the strict aliasing rule means you have to be a language lawyer to understand what is allowed and what isn't[5] as it makes the intuitive solution into undefined behaviour (which is extra pernicious since most of the time it will work as intended, until somebody compiles the code with a smarter compiler at a high optimisation setting).

[1] http://blog.regehr.org/archives/963

[2] http://blog.regehr.org/archives/914

[3] http://blog.regehr.org/archives/482

[4] http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf example 1

[5] http://blog.regehr.org/archives/959

TheCoelacanth• 13 years ago

Compared to other languages, 179 pages for the full specification is pretty small. Java and C sharp have that more than three that size. C++ is roughly five times as large. If you're a fan of functional languages, Haskell is almost twice as large. Even Scheme, an extremely simple language, is only about 30 pages shorter.

derefr• 13 years ago

I wouldn't say that any of that means that C itself is complex. It means your computer's native instruction-set architecture is complex (and full of undefined behavior), and C, being simple, just gives you relatively transparent access to it rather than trying to abstract it and standardize it and generally clean it up.

ctdonath2• 13 years ago

The size of the spec in part reflects the intensity and vastness of real world usage, having to get into painstaking detail regarding otherwise ignorable issues. It agonizes over minutiae because enough people are going into those dark corners that rules and expectations must be laid out for a profusion of obscurities.

If you have a relatively small number of users who understand the gist of the language, it can be expressed in a few pages.

If you want the language to be useful beyond a trivial description, you'll have to add some complexity, which leads to weaknesses.

If your language becomes world-scale popular, you're going to have to spend specification space dealing with things like explaining that under certain conditions yes in fact a Boolean variable can have a value other than "true" or "false".

joshuaellinger3• 13 years ago

By small, I meant that you can hold every little part of the syntax and normal behavior in your head pretty easily. Yeah, there are edge cases (important ones even) and you can build god-awful complicated expressions if you want. But look a the K&R books -- they are slim. It just not that big.

By not-doing-stuff-behind-your-back, I mean that you can map the code you write into machine instructions in many cases. An optimizer will move stuff around on you but it is typically local(-ish) manipulations. That's much less black magic that garbage collection. You have to manage memory yourself.

By being-ballet, I mean that it is hard. I am a swing dancer. The best dancers I know all took ballet classes as kids. None of them dance ballet today. It is probably coincidence/age but the best programmers I know all spent a decade or more working in C. I think working in C gives you a level of understanding about what a computer does that a higher level language doesn't. That said -- if you want to get stuff done, use a higher level language. I'm really good at C coding but I'm x2-10 faster when in C#.

joshuaellinger3• 13 years ago

1. Your first example ends with "C may be a small language, but it’s not a simple one."

By your argument, it feels like you'd say the language is large because you have to understand that rule if you really cared about consistent results everywhere. I agree with the author -- small but not simple.

Platforms differ and it leaks into the language precisely because it is such a simple language. It is simple like HTML 1.0 is simple. It is simple like the Bill of Rights is simple. There are a limited set of rules but there a lot of undefined behavior as a result.

I guess you believe HTML is complex because you have to understand CSS these days to do anything.

2. I find it interesting that you use what is clearly an edge case and then argue that because they are common it is not an edge case.

The example of "int foo(char x) { char y = x; return ++x > y; }" is almost the textbook example of an edge case. Seriously, don't trust me. Ask around and see if you can find 10 people who know C well that would consider this mainstream (excluding embedded developers).

There are countless serious bugs in real world C code because (a) there is so much damn real world C code and (b) it doesn't exactly protect from shooting yourself in the foot.

My experience working with a big program that ran on Windows, 2-5 flavors of UNIX, and VMS (both DEC and Alpha) is that the bulk of the real world errors in C code do not have anything to do with undefined behavior across platforms. They have to do with memory management (null pointers, buffer overruns, etc) and poorly written macros.

3. I agree with you that adding optimizers introduce a whole set of things you have to hold in your head that push you into 'large' territory. Just like programming on a GPU makes you rethink everything about how you organize code and writing for embedded code has its own set of rules.

But how does that make the language large?

My point is that a language that says "we manage memory on your behalf inside of a VM" is doing a lot more for you.

Boy, are we beating this thing to death or what...

...

I like C quite a bit but I wouldn't want to make a living programming in it today. I drop back into C when I have a compute kernel that needs it but 99% of the code remains in C#. C is small but too simple for the problems that I'm solving today.

Kurtz79• 13 years ago

"Terse" is the best adjective I can think of for C.

Merriam-Webster definition of "Terse" :

1: smoothly elegant : polished

2: using few words : devoid of superfluity

vadman• 13 years ago

Simple != easy, as per this great talk by Rich Hickey:

http://www.infoq.com/presentations/Simple-Made-Easy

JeanPierre• 13 years ago

To get an even better explanation on what the word "simple" means and what it derives from, I would recommend "Simplicity Ain't Easy" by Stuart Halloway[1]. While it is very similar to "Simple made Easy", it focuses a lot more on the etymology of the words "simple" and "complex" and how people misuse the word.

[1] http://www.youtube.com/watch?v=cidchWg74Y4

qdpb• 13 years ago

Nobody?

What these examples demonstrate is not that C is "hard", but that it's powerful.

pjmlp6• 13 years ago

There isn't a single feature in C that isn't present in more safer languages like Modula-2 or Turbo Pascal. They are as powerful, or even more, than C.

Just because C won the battle with those languages, it does not mean we need to live with its design issues ad eternum.

CoryG89• 13 years ago

How are you going to go about fixing C? And what design issues? It's pretty bare bones on top of the assembly. What should change?

EthanH• 13 years ago

Someone else at Cal summarized C succinctly when he wrote "C is the machete of programming languages. It's great for clearing a quick path through the jungle of programming problems, but be alert as there are no safety mechanisms to protect the wielder of this wonderful weapon." -David Patterson http://www.informit.com/promotions/promotion.aspx?promo=1389...

pjmlp6• 13 years ago

Warnings as errors, turn on all of them, pedantic mode and static analysers running alongside unit tests on every build.

Even then, there might be dragons waiting for you.

rootbear• 13 years ago

I would not have thought that

    return ({goto L; 0;}) && ({L: 5;});

was valid C. GCC 4.4.7 chokes on it, using -std=gnu99. Is this a C11 thing?

DerekL• 13 years ago

No, it's a GCC extension. That entire section is about non-standard GCC features.

apaprocki• 13 years ago

To the compiler, it shouldn't care where a label exists. If you're telling it to go to label L:, execution will jump there. GCC appears to look out for the programmer and always prints an error (and I don't see an option to shut it off). Oracle Studio compiles it with no issue and the above statement returns 1.

mikestew• 13 years ago

I just slapped it into Xcode and compiled using LLVM 4.2 (-std=gnu99), and it works fine. Using Xcode's LLVM GCC 4.2 setting (-std=gnu99 by default), it chokes.

Conclusion: I kind of lost interest at this point. :-) I don't quickly know how to get it to compile using GCC, though.

nautical• 13 years ago

https://news.ycombinator.com/item?id=6059249

harrytuttle• 13 years ago

All this proves is that you can write ugly C and GCC has some crocks in it.

These problems are all optional.

dvt2• 13 years ago

tl;dr: C is simple. Bad code is bad. Shitty compilers are shitty.

This needs to be qualified. Simple compared to what? C is simple when compared to C++, Java, and many other languages. Obviously, C is simple because it lacks syntactic sugar, classes, polymorphism, templating (generics), memory management, etc. So, uh, yeah. It's simple.

The fact that bad code can be written in a language doesn't really make the language non-simple. I could write bad code in any language (often times I do!) - so I'm not sure how any judgment about a language can be made with these kinds of examples. As far as the GCC/VC examples are concerned, they are a non-issue. Shitty compiler keywords are shitty[1]. We know. This is one of the many pains of writing cross-platform code in compiled languages. These examples are contrived and I highly doubt most come from production code.

[1] http://stackoverflow.com/questions/3437404/min-and-max-in-c/...

14113• 13 years ago

C is simple like the game Go is simple. Both are defined by (comparatively) simple rules, yet the possible situations that both present are far more complex than languages or games defined by far more complex rules.

kbenson• 13 years ago

In that vein, assembly languages are even simpler. Which is true. The languages themselves are simple. Their use often isn't.

Demiurge• 13 years ago

C is not simple because its BNF is not simple and hard to interpret. You can have a simple (feature wise) C like language with a much cleaner syntax. ie Pascal, Modula, Oberon. You can simplify it a lot just by dropping += :)

lmm2• 13 years ago

Signed/unsigned conversions and conversion to/from pointers of functions and arrays cause real, production-code confusion. In terms of how much mental overhead the language takes up - how many edge cases you have to keep in mind to read code in the language (because if you're programming right then you spend more time reading than writing) - no, it's not simpler than Java, because classes, generics and memory language are more straightforward and less confusing than C's typing rules.

Languages have a complexity budget, and C blew its on a squillion different kinds of integer and a bunch of arbitrary-seeming rules to minimize the amount of typing needed to change between them. That was a good tradeoff in its day, where hand-optimization was practical and program source needed to be small. It's not an appropriate language to use now outside of very specific circumstances.

dvt2• 13 years ago

You say this as if Java doesn't have its fair share of oddities. It seems you're saying that the highly granular typing found in C doesn't have an equally-annoying analogue in Java; it does[1].

[1] http://www.javalobby.org/java/forums/m92125315.html

rdtsc2• 13 years ago

Who Says C is Simple?

I do.

C is like chess. There are few simple rules (compared say to C++ spec). But knowing the rules doesn't mean you'll end up beating Kasparov. It still takes skill and practice to be a good C programmer.

So, the language itself, is pretty simple compared to other popular programming languages as far as it has a simple syntax. I can teach someone the rules of chess pretty quickly, It doesn't mean I'll create a chess grand-master in a day or two.

gnuvince3• 13 years ago

The difference is that I don't want my programming language to take me a lifetime to become reasonably skilled with it. There are many languages that are simpler than C, and easier to use as well.

foobarbazqux• 13 years ago

I bet most or all of the languages that you're thinking of run on a VM written in C.

cygx• 13 years ago

> Who Says C is Simple?
I do.

I disagree. C comes with a lot of edge cases and subtleties that can surprise even people like myself who 'know' C.

Some examples: Exact semantics of restrict, C99 inline semantics (eg I wasn't aware that it's possible to make a non-extern/non-static inline definition into an extern one with a single redeclaration), effective typing rules and whether it's possible to circumvent them, whether or not it's undefined behaviour to cross boundaries of the sub-arrays of a multi-dimensional array if it doesn't happen in a single expression, ...

rdtsc2• 13 years ago

The difference is between gimmicky ways one can use ambiguity to produce convoluted edge cases vs knowing enough to do actual work. Sure C being low level and and having a relatively short specification is ripe for compiler specifics and hardware specific hacks. But still think it has the basic core defined and that is pretty small.

With C++ and its typical libraries it is a bit different. It has so many features (templates, classes, streams, friends, shared pointers, unique pointers, distructors, constructors, polymorphism rules, and combination of those) that code gets complicated without using obscure features, just sticking to the standard ones gets hairy and needs someone who knows the whole spec.

alco• 13 years ago

Why does the following code return 0 and not -1?

This questions appears twice in the article.

Note that shifting a 32-bit integer (no matter the sign) by 32 is undefined behavior (§6.5.7, 3). I'm using Clang, and its `int` has 32 bits even on a 64-bit system.

C is deceptively simple.

null_ptr• 13 years ago

These little teasers are starting to annoy me. Congratulations, you can twist C to be as unintuitive as you'd like it to be. But why would you write code like that to begin with? I don't care what value __ return -3 >> (8 * sizeof(int)); __ returns because no sane program anyone contributes to will have constructs like that.

eps• 13 years ago

You are missing the context, which is that of an unambiguous parsing of any valid C code. Examples given are teasers for the parser, not a prorammer.

ximeng• 13 years ago

"The following examples were actually encountered either in real programs or are taken from the ISO C99 standard or from the GCC’s testcases."

acjohnson55• 13 years ago

C is not a simple language. It is confoundingly difficult for a machine to parse. Add in the fact that it pretty much requires a preprocessor to be useful and it get's even more difficult. Clearly the article is not about whether the C paradigm is complex. It obviously isn't, because it doesn't come with a whole lot of pre-baked abstractions. But for parsing reliably, it's an absolute nightmare.

auctiontheory• 13 years ago

C is a tool. A powerful and flexible tool.

If a programmer wants to write obfuscated code (as in the examples), C allows that.

If a programmer wants to write clean, maintainable and documented code, C allows that too.

bwy• 13 years ago

Go Berkeley, awesome prof.

Who Says C is Simple?

Related Stories