The IOCCC Competition Is Back

← Back to Stories (view on slashdot.org)

The IOCCC Competition Is Back

Posted by samzenpus on Sunday November 13, 2011 @06:22AM from the welcome-back dept.

Rui Lopes writes "After a 5 year hiatus, the IOCCC (International Obfuscated C Code Contest) is back! This marks the 20th edition of the contest. Submissions are open between 12-Nov-2011 11:00 UTC and 12-Jan-2012 12:12 UTC. Don't forget to check this year's rules and guidelines."

64 of 201 comments (clear)

Min score:

Reason:

Sort:

It'd be nice if ... by fsckmnky · 2011-11-13 06:25 · Score: 5, Insightful

They created a competition for the most well structured, well documented, clean and correct code.

Most C coders seem to achieve obfuscation without any additional incentive.
1. Re:It'd be nice if ... by phantomfive · 2011-11-13 06:27 · Score: 5, Interesting
  
  But then we never would have a piece of code that calculates its own area. Isn't that worth it? (LINK).
  
  --
  "First they came for the slanderers and i said nothing."
2. Re:It'd be nice if ... by masternerdguy · 2011-11-13 06:35 · Score: 5, Insightful
  
  This is a good competition because it helps exploit the guts of C in new and exciting ways. Go back to your clean and neat database client if you can't play with the cowboys.
  
  --
  To offset political mods, replace Flamebait with Insightful.
3. Re:It'd be nice if ... by Hazel+Bergeron · 2011-11-13 06:37 · Score: 5, Insightful
  
  Most C coders seem to achieve obfuscation without any additional incentive.
  Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
  Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year, each with their uninteresting quirks of syntactic sugar, competing on the basis of some uniquely uninteresting difference which can almost always be trivially implemented in any of the alternatives. They are hard to read in the same way that German is hard to read to someone who has only been reading German for a year: skill and speed comes through practice with the language, not from the ego of its authors.
4. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 06:42 · Score: 5, Funny
  
  Yeah, Python sure flooded the marketplace in the past year. Now, if you'll excuse me, I've got to check the breaking news about the Lewinsky scandal after buying some hot dot-com stocks while on the way to work at the World Trade Center because apparently it's the late nineties again somehow.
5. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 06:46 · Score: 5, Insightful
  
  Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
  Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year, each with their uninteresting quirks of syntactic sugar, competing on the basis of some uniquely uninteresting difference which can almost always be trivially implemented in any of the alternatives. They are hard to read in the same way that German is hard to read to someone who has only been reading German for a year: skill and speed comes through practice with the language, not from the ego of its authors.
  +1, it all started going downhill when :
  - professional language designers abdicated their role, and the void was filled by amateurs
  - people who use these languages have no fucking clue what they're doing and we're all paying the price
  - corporations hyped languages for their own purposes and languages stagnated or worse were crapified to an absurd level (witness java).
6. Re:It'd be nice if ... by Rosco+P.+Coltrane · 2011-11-13 06:51 · Score: 4, Interesting
  
  Most C coders seem to achieve obfuscation without any additional incentive.
  You got it wrong: bad coders create bad code. Good coders know how to create good code. In any language.
  When someone knows C well enough to create a truly obfuscated or compressed piece of portable C code that follows the rule of the language to a tee, i.e. that can be compiled strict or linted, and wins the IOCCC, it's a very good sign that this someone can create excellent C code.
  I should know, I won the IOCCC years ago, and used it many times in my resume. When would-be employers told me "what's the IOCCC?", I knew they weren't going to be good employers. When they told me "oh, I see you won the IOCCC", they knew I could code good C, and I knew they groked what I did. Winning the IOCCC helped me land a job a few times.
  
  --
  "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
7. Re:It'd be nice if ... by tgv · 2011-11-13 06:54 · Score: 3, Insightful
  
  Sure, that could be nice as well, but the IOCCC provides great challenges and puzzles, something that a clean code contest wouldn't. And what would you rather see in your news paper: difficult puzzles or easy ones? Or, for the youngsters here: would you rather play word feud, or type the answer to 1 + 1 over and over again?
  Besides that, the IOCCC entries contain mostly well structured and correct code, and afterwards they get documented as well. It's just not readable.
8. Re:It'd be nice if ... by 93+Escort+Wagon · 2011-11-13 06:59 · Score: 3, Funny
  
  Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
  Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year, each with their uninteresting quirks of syntactic sugar, competing on the basis of some uniquely uninteresting difference which can almost always be trivially implemented in any of the alternatives. They are hard to read in the same way that German is hard to read to someone who has only been reading German for a year: skill and speed comes through practice with the language, not from the ego of its authors.
  Wow! Dr. Ritchie, everyone thought you were dead!
  
  --
  #DeleteChrome
9. Re:It'd be nice if ... by Khyber · 2011-11-13 07:10 · Score: 2
  
  Go look up the Demoscene.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
10. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 07:13 · Score: 4, Insightful
  
  Closed source code is the same, only you don't get to see it.
11. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 07:25 · Score: 2, Insightful
  
  I'm going to say that open source is bad and pre-emptively brand all disagreement as fanboyism so that my opinion is taken as authoritative.
  FTFY
12. Re:It'd be nice if ... by Rosco+P.+Coltrane · 2011-11-13 07:37 · Score: 4, Informative
  
  Maybe I'm a little older than you think? :)
  
  --
  "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
13. Re:It'd be nice if ... by gomiam · 2011-11-13 07:49 · Score: 2
  
  You can sigh all you want. Lousy programmers will write lousy code whether it is open source or not, whether it is C or not. I know, I have had to maintain it (and certainly written it at some time). Just sprinkle ten or so non-named constants in your code to signal for some database offsets and you are in for a few entertaining hours/days of repurposing.
14. Re:It'd be nice if ... by Goaway · 2011-11-13 08:01 · Score: 2
  
  Let me tell you, no demo code is ever anywhere near well structured, well documented, clean or correct.
15. Re:It'd be nice if ... by petes_PoV · 2011-11-13 08:13 · Score: 4, Insightful
  
  Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
  Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year.
  This clearly shows you simply don't understand the problem. A good programmer can (and does) write well structured, clean, DOCUMENTED and maintainable product in any language. The issue has nothing to do with the language used and everything to do with lack of discipline, inexperience and a slapdash and unprofessional attitude. Usually the worst programmers are the ones who think that once the code is written and compiles clean, the job is done. For most of these people there is little hope of educating them as they are incapable of seeing the bigger picture.
  
  --
  politicians are like babies' nappies: they should both be changed regularly and for the same reasons
16. Re:It'd be nice if ... by wavedeform · 2011-11-13 09:15 · Score: 2
  
  You got it wrong: bad coders create bad code. Good coders know how to create good code. In any language.
  My favorite programming adage: "You can create bad Fortran in any language."
17. Re:It'd be nice if ... by martin-boundary · 2011-11-13 09:38 · Score: 3, Funny
  
  Great Scott! You're in a TIME LOOP! Don't move! There's a car to your left, get in slowly and accelerate to 88mph down the street. Oh, and here's a banana peel for the FUSION REACTOR.
18. Re:It'd be nice if ... by shagie · 2011-11-13 09:43 · Score: 2
  
  Pardon me, but are you serious? Claiming that code is clean (or correct) because it compiles to a small executable isn't necessarily true. The demo scene prides itself on small executables and optimizes for this. Such optimizations are rarely the product of clean and correct code but rather hand crafted dark compiler (or assembler) magic.
19. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 09:56 · Score: 4, Interesting
  
  You're making basically the same argument as people were saying back when machine code was what people wrote and C was new. If you have an open mind, you can easily see that C has serious shortcomings by modern language standards.
  C offers no abstractions for complex data types. It offers no subtyping. There's no facility for generic programming other than macros, which everyone knows suck. No support for closures or comprehensions. None of these things are "trivially implemented", as you state. Even its syntax sucks, as anyone would agree who's tried to declare a non-trivial function pointer.
  Many common programming tasks require extensive pointer manipulation in C. Even the best programmers (I'm one of them, and I concede this point) make ocassional mistakes with pointers, and they are the worst kind of bug: silently incorrect or a crash at a random place in the code.
  C is perfectly appropriate for some projects, especially with really low-level code (as most C constructs translate directly to assembly). C++ is usually better, as it has a richer typing system and ability to do generic programming, but you need to be an expert as the language is full of pitfalls (which are mostly C's fault). For projects that don't need to be close to the hardware, scripting languages can multiply programmer productivity.
20. Re:It'd be nice if ... by Joce640k · 2011-11-13 10:31 · Score: 2
  
  Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
  An upgrade to C++ is a very good idea though.
  
  --
  No sig today...
21. Re:It'd be nice if ... by gomiam · 2011-11-13 11:14 · Score: 3, Funny
  
  I would suggest you take up dubbing the Twilight movie series. You seem to have half their dialogues pat down.
  Back on track, do you have anything useful to add besides pining for the fjords?
22. Re:It'd be nice if ... by antifoidulus · 2011-11-13 11:23 · Score: 3, Insightful
  
  while some smart programmers think it's necessary to over-use the preprocessor
  
  And that is ultimately my main beef with C, it's impossible to write non-trivial code that DOESNT make use of the pre-processor. Header guards in 2011? Really? C either needs to make an Objective-c like import statement a standard or else make #pragma once standard and make it default, so that if in the rare case you do actually need to include a file more than once, THEN you have to use a pre-processor command. I think the pre-processor is a really useful feature of C, but it should never be essentially mandatory to use it.
  
  --
  Monstar L
23. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 11:27 · Score: 2
  
  I would hope that no one who actually knows what they're doing would ever create a type with the name __MfxVge__, because symbols starting with a leading double underscore are reserved for use by the implementation. You knew that right? Right? Obviously, because you know how to write comments and spell out complete words.
24. Re:It'd be nice if ... by Khyber · 2011-11-13 12:31 · Score: 2
  
  Considering I have done some demos myself, you'd be wrong.
  The software running my entire research facility is in 4K, that's network stack, video feed controls, nutrient/water monitoring, the works.
  You don't get good small executables writing crappy code.
  Period.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
25. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 12:45 · Score: 2, Insightful
  
  While your code may be technically correct, compile, and do what it's intended to do, that does not make it good code. It just makes it code that works.
  Look at IOCCC examples posted on wikipedia. If the average programmer (ie: your coworker) will need to spend more time thinking about the extra whitespace and the syntactic monstrosity that comprises the competition, then your code design sucks and you've ended up causing more headaches with your "good" code.
26. Re:It'd be nice if ... by stanlyb · 2011-11-13 16:04 · Score: 2
  
  If you sometimes made some mistakes with pointers, occasionally, it is 10000 times better than what an unexperienced C# developer could do with all the neat language features, you simply have no idea how obfuscated his code could become, and how much you begin to like the idea of having revoked the death penalty...
27. Re:It'd be nice if ... by Austerity+Empowers · 2011-11-13 16:53 · Score: 3, Funny
  
  Java is NOT an upgrade to C++. There was a fork in the road, to the left went C++ to the right went Java. C++ took you through a swamp filled with poisonous snakes, quicksand and man eating spiders. Java took you through a haunted forest, with werewolves and zombies.
  No matter which path you took, you died before reaching your goal.
28. Re:It'd be nice if ... by phantomfive · 2011-11-13 17:40 · Score: 5, Informative
  
  Many common programming tasks require extensive pointer manipulation in C. Even the best programmers (I'm one of them, and I concede this point)
  
  I'm seriously doubting your professed skill here. You don't ever have to do pointer arithmetic in C, unless you are counting parameter passing as 'extensive pointer manipulation,' but you pass parameters as pointers in Java too (that's why you can get an NPE). The most common use of pointer arithmetic is for array processing, but if you want to be safe you can just use the array[] notation and not worry about understanding pointer arithmetic (I usually do, unless I have a compelling need to use pointer arithmetic). Furthermore I don't even know what you are talking about when you say, "non-trivial function pointer." Aren't all function pointers the same, just a bunch of parameters and a return value? Or are you declaring an array of function pointers or something? That might be where your problems are coming from.
  
  From experience I can say by far the thing that takes the most extra time when I am writing in C (compared to Java) is the lack of a good library, with common data structures like hash tables and lists and regular expressions. The number of times I've had to write a generic list library for some random platform, or figure out someone else's nonstandard implementation, is depressing.
  
  Also the generics in Java are a double edged sword. They allow more flexibility, but allow you to get away with writing incredibly confusing code, that can be extremely difficult to understand without a debugger. C code (really) tends to be a lot more readable. The downside is that it's usually a lot easier to refactor Java code without needing to rewrite a lot of interfaces (even when the interfaces were poorly written in the first place).
  
  Ultimately though, a good programmer will write good code in any language. A poor programmer will likewise write poor code in any language.
  
  --
  "First they came for the slanderers and i said nothing."
29. Re:It'd be nice if ... by bertok · 2011-11-13 18:57 · Score: 2
  
  Sounds great, but all that nice sounding theory doesn't apply in practice. For example, C and C++ in particular are languages that started out "simple" but became quagmires over time. It's impossible to write portable C/C++ code that meets your requirements of "well structured and clean".
  Haven't you noticed how every cross-platform C/C++ library starts out with pages of pages of "MY_LIBRARY_INT32" and "MY_LIBRARY_EXPORT" and other redefinitions of "standard" types, keywords, and functions? That's because C is a badly designed language where the behaviour and/or availability of even basic language keywords like "int" is a crap shoot that depends on the compiler and the target processor type. This then makes each library wonderfully unique and special, with their own macros to paper over this inconsistency.
  Compare this to, say, C# or Java, where "int" is always exactly 32 bits and signed, no matter what. This means that if I pick up some random library off the web for some obscure purpose, it just works, and I'm don't have to figure out what the "int" type really means, or if it'll match the "int" type in some other library. I could go on about how every C library needs to redefine such basic concepts as memory allocation, or has a unique and special way of handling buffers or streams -- I'm sure you get the idea. No matter how skilled a programmer is, they will end up having to do the same kind of thing, because the language provides no real alternative, and the standard library is very small, and not very standard.
  I recently had to pick up a C compression library, which had a simplified version for users who "didn't need all the fancy features of the full version". It had a 50KB header file, 99% of which platform-detection, followed by... five actual function definitions. Three of those were for memory management -- because everything needs that to be reinvented, clearly. How is this "clean"? What would you do to make this "clean", without dropping cross-platform support?
  Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
  public class Compressor {
  public byte[] compress( byte[] data ) { ... }
  public byte[] decompress( byte[] data ) { ... }
  }
  A tad "cleaner" than 50KB of macros, don't you think?
30. Re:It'd be nice if ... by PeterBrett · 2011-11-13 20:43 · Score: 2
  
  Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
  I'll switch to using a language other than C when a language other than C allows me to use wait-free shared-memory multiprocessing algorithms.
  
  --
  Pirate Party UK
31. Re:It'd be nice if ... by JasterBobaMereel · 2011-11-13 20:52 · Score: 2
  
  IOCCC code is hard to read
  DemoScene code is efficient
  Both are normal code taken to extremes
  
  --
  Puteulanus fenestra mortis
32. Re:It'd be nice if ... by shutdown+-p+now · 2011-11-13 22:15 · Score: 2
  
  http://thedailywtf.com/Articles/The-Integer-Cache.aspx
  It's a WTF. What, you never saw a C or C++ WTF?
  
  And it seems that you need a string builder class to help you manipulate strings. Sorry, but that tells me that you're doing strings wrong.
  It's one of the tradeoffs that you have when you design what your strings look like. In C++, they are mutable, but they are "value types" in Java terms - i.e. copying them around actually copies the buffer, so when you pass a string to a function, it can freely mutate it since it has the pointer. But copying like that ain't cheap - it's why you have to pass by const reference where possible. Often can't return by reference, though. RVO (and, in C++11, move semantics) help with that somewhat, but you're still almost certainly doing some unnecessary extra copies with those strings in any moderately complicated C++ progam.
  In Java, strings are reference types (or, in C++, you could treat it as a value type with a pointer to the buffer). Since there's no easy way to copy the buffer when passing by value (and requiring the caller to do so explicitly on every call would be very tedious), the only way to prevent the callee from mutating the referenced, potentially shared string is making it immutable. then you need a helper mutable class like StringBuilder to help you build those immutable strings in an efficient way, since otherwise you'll be allocating and throwing away a new immutable string on every iteration. On the other hand, strings tend to be just created once and passed around much more often than they are mutated, so this design has better perf for the most common case.
  Ruby (at least in 1.8) had a pretty insane design in that strings are reference types (same as everything else), but they're also mutable - so you have to be extra careful make a copy of the string in the function if you're planning on changing it, and copy the returned string value in case the caller tries to change it.
33. Re:It'd be nice if ... by shutdown+-p+now · 2011-11-13 22:17 · Score: 3, Insightful
  
  It's "broken" in a sense that, if you try real hard to break it, you can find ridiculous corner cases that can do that. In the meantime, there are millions of line of C and C++ code written using it, which compile and work just fine.
34. Re:It'd be nice if ... by PeterBrett · 2011-11-13 22:19 · Score: 2
  
  java.util.concurrent.atomic is a perfect example of why Java is not a viable choice for the work I'm doing. One of the tasks I currently have to handle is multiprocess disjoint set construction (using the wait-free union-find algorithm), on a very large corpus. This algorithm requires each disjoint set tree node to contain two fields: a reference to its superset, and a rank counter. In Java, the only choice I have is to use an array of AtomicStampedReference<V>, which will always occupy at least two platform words. Because I know the exact size of the corpus, in C I can easily do some trivial pointer arithmetic to halve the amount of storage required on 64-bit platforms. Not only does this allow me to process larger datasets on my workstation without suffering from memory exhaustion, but because the computation turns out to be memory bandwidth-limited, it allows me to process it faster as well.
  Oh, and .NET can DIAF.
  
  --
  Pirate Party UK
35. Re:It'd be nice if ... by BenoitRen · 2011-11-13 23:46 · Score: 3, Interesting
  
  Haven't you noticed how every cross-platform C/C++ library starts out with pages of pages of "MY_LIBRARY_INT32" and "MY_LIBRARY_EXPORT" and other redefinitions of "standard" types, keywords, and functions? That's because C is a badly designed language where the behaviour and/or availability of even basic language keywords like "int" is a crap shoot that depends on the compiler and the target processor type
  
  Well, duh. That's the entire point of C. You're complaining that it's a language close to the metal.
  Still, since C99 there are special integer types available that define exactly how large they are and if they're unsigned or not. Yes, they are widely available. It's been over 10 years since their introduction.
  
  Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
  
  At least until Java decides to deprecate parts of its standard library. Java code written during the 90s no longer works. So much for "write once".
36. Re:It'd be nice if ... by Rob+Seace · 2011-11-14 00:11 · Score: 2
  
  But can't be used to represent characters, because Unicode requires at least 16 bits for the character type.
  Never heard of UTF-8 then, I take it? That works fine in regular old char arrays... (Though, to be fair, it introduces other issues, such as you can no longer depend on the length of the string being the number of characters in it...)
Underhanded C contest should return by vadim_t · 2011-11-13 06:36 · Score: 5, Interesting

The IOCCC is cool, but the Underhanded C Contest was a lot more valuable.
The entries for the IOCCC can show a lot of cleverness, but nobody in their right mind would accept such code. The beauty of the Underhanded C ones is that the code looks reasonable, but does extremely undesirable things.
1. Re:Underhanded C contest should return by Truekaiser · 2011-11-13 06:57 · Score: 3, Interesting
  
  call me paranoid but this contest and the ioccc are the reasons why i don't particularly let anything from s.e.l. touch my systems. i am not a good enough coder to be able to tell if what it's doing is what it says it's doing or something the cia wants it to do..
2. Re:Underhanded C contest should return by martin-boundary · 2011-11-13 09:31 · Score: 5, Insightful
  
  Then you should read Ken Thompson on putting backdoors in C compilers. Do you trust your build system?
3. Re:Underhanded C contest should return by martin-boundary · 2011-11-13 13:55 · Score: 2
  
  s.e.l.
This makes me so happy... by Anonymous Coward · 2011-11-13 06:36 · Score: 2, Insightful

I hope there are many submissions... It's things like this that teach you the FULL amount of abuse a language can take while still making something that works. :-D
I would like to see this rule illustrated by bogaboga · 2011-11-13 06:36 · Score: 2

To illustrate some of the subtleties of the C language.
The C language is not my thing per se, but I'd like to see simple C program code the illustrates the subtleties of C. Anyone?
1. Re:I would like to see this rule illustrated by Anonymous Coward · 2011-11-13 06:49 · Score: 4, Insightful
  
  Look up "Duff's Device". There's a good example.
2. Re:I would like to see this rule illustrated by Bomazi · 2011-11-13 07:47 · Score: 2
  
  This link:http://www.eecs.berkeley.edu/~necula/cil/cil016.html
  describes some corner cases of C. You need to have some prior to knowledge of C to appreciate the non-obviousness of the examples though.
Awesome! by Anonymous Coward · 2011-11-13 07:13 · Score: 4, Funny

It's about time I got some more reference code.
1. Re:Awesome! by achowe · 2011-11-14 02:58 · Score: 2
  
  http://www.ioccc.org/winners.html#H Look at Anthony C Howe (me). 1991 (vi clone in 1526 bytes source, went on to become the floppy disk rescue editor "ae" in early Debian) and 1993 (egrep) are particularly interesting for their data structures. My favourite from someone else is http://www.ioccc.org/ /years.html#1992_buzzard.2 (forth clone); took me ages to understand this this gem way back then. And for those who think I'm bragging, shit ya, since the IOCCC has no real prize, they say bragging rights is all the winners get.
  C is not about being cryptic, though it certainly can be when done badly. Its about clever data structures, being methodical, disciplined, where small is beautiful; instead of memory and CPU cycles being cheap.
  Another great C example is the early "Empire" http://www.classicempire.com/ before there was fancy graphics and Sid Meyer's Civilisation.
Re:Use Duff's Device by JonySuede · 2011-11-13 07:27 · Score: 5, Interesting

don't use them anymore, go read that post: http://lkml.indiana.edu/hypermail/linux/kernel/0008.2/0171.html

--
Jehovah be praised, Oracle was not selected
Re:Use Duff's Device by Anonymous Coward · 2011-11-13 08:06 · Score: 5, Interesting

Jim Gettys has a wonderful explanation of this effect in the X server. It turns out that with branch predictions and the relative speed of CPU vs. memory changing over the past decade, loop unrolling is pretty much pointless. In fact, by eliminating all instances of Duff's Device from the XFree86 4.0 server, the server shrunk in size by _half_ _a_ _megabyte_ (!!!), and was faster to boot, because the elimination of all that excess code meant that the X server wasn't thrashing the cache lines as much.

Emphasis mine. That's REALLY freaking interesting. Posting this AC before modding you up.
The Internet is based on C by Required+Snark · 2011-11-13 08:12 · Score: 5, Insightful

I find all the "C sucks" comments to be both amusing and stupid. Without C code there would literally be no Internet. Every bit you are sending and receiving uses C. The two operating systems that represent 99.99% or more of the running computers that are online run C. Both Windows and Linux use the BSD TCP/IP stack.
If C did not get the job done for this kind of computing then it would have been replaced. The fact that C thrives in the systems programming domain is a tribute to it's utility.
A proficient C coder can write clear, maintainable, efficient code that runs on many platforms. This requires both skill and practice. Not everyone is capable of doing this. It requires the ability to keep multiple competing abstractions in mind when coding. I think a lot of people try this and find it difficult and then blame the language. Those who persevere and learn this style of working can usually move on to other kinds of programming and also do excellent work.
Some problem domains require different languages and different skill sets. Personally, I like writing code where I know that if I were to look at the assembly code generated by the compiler I can see how it relates to the C code I wrote. I rarely do this, but it's good to know that I can if I want to. I'm doing any C coding now, because I always use the appropriate language to the task. But I also know that my C coding skills give me a distinct advantage in solving difficult problems, no matter what they are,

--
Why is Snark Required?
1. Re:The Internet is based on C by Sduic · 2011-11-13 09:26 · Score: 5, Interesting
  
  Without C code there would literally be no Internet.
  Because obviously only C is Turing-complete.
  Before I stir up any vitriol, I'm just kidding. I think C is under appreciated precisely because is provides only a thin abstraction that (hopefully) maps well to the target architecture, but otherwise stays out of the way. That is to say, when all you have is a hammer, you can easily shoot yourself in the foot.
  
  --
  *this space intentionally left blank
  "One of the four pointers saying 'come and see', and I saw, and beheld a white
2. Re:The Internet is based on C by dlgeek · 2011-11-13 09:55 · Score: 3, Informative
  
  #include
  uint16_t x = 0; /*unsigned 16 bit integer */
  int32_t y = 0; /*signed 32 bit integer */
  
  Almost every platform I've ever worked on has stdint...
3. Re:The Internet is based on C by mdf356 · 2011-11-13 10:48 · Score: 3, Insightful
  
  stdint.h came in with C99. There were decades where people hand-rolled their own versions so network communications would work...
  
  --
  Terrorist, bomb, al Qaeda, nuclear, yellowcake, kill, assassinate. Carnivore is dead... long live Echelon.
4. Re:The Internet is based on C by mdf356 · 2011-11-13 10:52 · Score: 5, Informative
  
  - I think people who put the "*" of pointer syntax near the variable name and not the type name when declaring pointers should be shot. It should always be int* pointer_to_int, not int *pointer_to_int.
  I'm sure my complaints are unwarranted except for the first point.
  But that's backwards of what the compiler really does. Consider this:
  int* p, q;
  What types do p and q have? p is a pointer-to-int; q is an int. By putting the * next to the type name it makes it look like all the things are int*, but they're not. By putting the * with the type (which I did for my first year of C coding) you're making reading the code harder rather than easier. It'd be like writing
  a = b * c+d;
  and trying to convey that the '+' binds tighter since it doesn't have spaces. That's not what the compiler will do and writing it so only serves to confuse the reader.
  In addition, what you see at declaration is representative (modulo the weirdness of array subscript and pointer deference) to what you'd do to get the type. That is, int ***p means that you'd have to type ***p to get an int. *p means you'd need another ** to get an int, etc.
  
  --
  Terrorist, bomb, al Qaeda, nuclear, yellowcake, kill, assassinate. Carnivore is dead... long live Echelon.
5. Re:The Internet is based on C by Carl+Drougge · 2011-11-13 11:10 · Score: 2
  
  Keyword: cognitive load. Case in point: hilariously excrutiating code example in linux man page of snprintf. If you need to jump through all these burning hoops to do something this mundane, imagine how much more your proficient C coder could achieve in a more sensible laguage with the same amount of effort.
  A sensible C coder might use vasprintf instead of the example in that manpage. The fact that all the standard library functions aren't great for all (or sometimes any) use cases is hardly unique to C.
6. Re:The Internet is based on C by martin-boundary · 2011-11-13 14:22 · Score: 3, Insightful
  
  Nonsense. Windows security flaws have historically been due to boneheaded design decisions. Windows was never meant to run as a node on the internet, that functionality was retrofitted when Bill decided to do his famous 180 about turn on the computer highway because he'd missed the internet on-ramp. "Security" was retrofitted ten years later.
  Problems with the C standard library certainly do exist and can expose security issues, but Windows security problems exist because the OS design emphasises user friendliness and backwards compatibility over tight protections.
  It's like inside your home, you don't lock all your cupboards, drawers and doors - that would be painful, eg to walk from the kitchen to the living room you'd take out your key, unlock the door, open go through shut, relock the door, each time. To make your home livable you keep it insecure, and that's how Windows was designed from the ground up.
  But now suppose there's a magic internet wormhole that opens in your toilet room, and anybody can enter your house. Suddenly it makes sense to have locks on all the doors and cupboards etc, but it's too late. Windows + Internet = insecure.
  Unix doesn't have this problem, because Unix was always designed as a hotel (multiuser OS) rather than a home. So there's locks on the rooms and the swimming pool needs an access card etc. If a wormhole opens in the hotel lobby or even in one of the guest rooms, there's limited access to most areas by design.
7. Re:The Internet is based on C by DMFNR · 2011-11-13 17:30 · Score: 2
  
  Actually during the creation of NT Microsoft licensed a network stack from Spyder Systems, which was based on the BSD TCP/IP stack. Microsoft replaced this with it's own stack for NT 3.5, which was the second version, and I believe that was the one that went in to Windows 95. Some small userland utilities persisted after the stack was replaced, and who knows how much BSD code Microsofts own network stack contains even to this day seeing as we can't review Microsoft's source. Not that it really matters, as the BSD license doesn't require them to release the source, just to provide credit to the original developers, and I know these were present in some of the utilities at least up to XP, and I'm sure if the included any BSD code in their current network stack they would have the attribution hidden somewhere in fine unreadable print.
8. Re:The Internet is based on C by martin-boundary · 2011-11-13 20:14 · Score: 2
  
  Actually, I think I fucked that one up. The bit size is exact, but there is no guarantee that the typedef for a particular size exists, so technically you can't rely on uint16_t in your programs anyway.
  The people on the standards committes are either saints, or abject evil scum. Maybe they're in a quantum superposition of both states, as long as you don't open the ISO report and take a look...
Platforms that can't run C by tepples · 2011-11-13 08:31 · Score: 2

The kind of crap that would be easier to rewrite than refactor?

How about stuff that needs to be rewritten from scratch because a target platform can't run C? This is true of the web (or at least it was until Emscripten), and it's still true of Xbox Live Indie Games and Windows Phone 7.
Re:Use Duff's Device by TheRaven64 · 2011-11-13 09:30 · Score: 4, Insightful

It's the main reason why C++ does well in microbenchmarks and does so much worse in real-world usage. It encourages a lot of inlining, which reduces branching but increases instruction cache usage. It's difficult to benchmark well, because instruction cache pressure changes over time depending on what else is happening with the system.

--
I am TheRaven on Soylent News
Because D is such a heavily used language... by Anonymous Coward · 2011-11-13 11:50 · Score: 5, Insightful

A number of quick points... Some people just don't know, so here are some practical speaking points...
-C has been around longer than most of the non-C programmers alive. That includes you people on this site, which has the smartest people, from one of the most divisive areas in the civil space: the "tech wars".
-D was such a better language... also, C++ because we never hear about C anymore.
-Java is on it's way out, being deprecated by the largest company in the world, which also deprecated Flash (on mobile) which Adobe just acquiesced to, replaced by Google's new iteration. Maybe not in the next 5 years, but it can no longer grow... it will have to get smaller with less support.
-Objective-C, used by Apple Inc., the largest company in the world, is a wholly-compatible superset of (ANSI) C. There are no signs of change here. Big surprise, it's all the same hardware components, just in larger capacities, at faster rates, and smaller form-factor. C can't help us with the flux capacitor... but that has not been added to the standard CPU, memory, memory storage, etc. model.
-Google announced that Android will run a C-like-language in the native space that uses the CPU and GPU. Even with Dart coming our way...
-CUDA... C is relevant in other (all) GPU spaces which is the go-to-guy, for the moment, to eak out more performance from a machine.
-And here is where the feelings get hurt: In college, I strattled the EE/CS line while being firmly EE. EEs learn C because it teaches them valuable things about the hardware, being a very light obfuscation. CS departments tend to concentrate on, well, anything else. Flavors of the year, interesting projects, etc. That is their place. My older brother went the CS route, 8 years before I got my turn and went EE. I admire him and his success greatly but I know, push came to shove, I can talk about certain topics without talking about garbage collectors and universal typing.
So, please, if you've never used C in any significant way, just don't comment. Listen. People, young and old, have something to tell you about the most significant programming language ever invented.
And to bring this all together: When you are trying to eke out CPU cycles so your 3D rendering is above 60 fps on that mobile device, you will know why closeness to hardware and C, in particular, may be your best friend. Or a C-like language...
Another way to look at it: People who know C and have worked with it, can't just unknown it. They know what you non-C people know, but also have other experience. If MOST of them say C is indispensable, then how about you do the one thing some Tech Asshole never do: Take someone else's advice. And STFU.
Can we just talk about something else that is awesome and not caught up in this stupid argument?
1. Re:Because D is such a heavily used language... by Anonymous Coward · 2011-11-13 12:14 · Score: 3, Funny
  
  People, young and old, have something to tell you about the most significant programming language ever invented.
  You mean LISP? I haven't seen anyone mention it yet.
Perl.. by bored · 2011-11-14 03:51 · Score: 2

I can't believe no one has mentioned this yet!
But, before perl, what was Larry Wall famous for?
Winning the IOCCC, not once, but twice.
Makes you think...
Re:Use Duff's Device by Toonol · 2011-11-14 03:58 · Score: 2

I wonder if FORTH would be particularly efficient on today's processors, for that reason? It is incredibly compact, with generally tiny functions nestled deeply. An entire FORTH system could sit in a modern cache.