Slashdot Mirror

The link to the winners and descriptions is, http://www.ioccc.org/2011/whowon.html

Tell that to the PHB that wants the code to ship YESTERDAY--bugs or no bugs!

To me, proper programming is and exercise in minimalism--get the most work you can out of the simplest and least least amount of code.

Then comments/documentation isn't so critical.

But that takes too long and time is money to the average PHB. So you get apps that barely work and must be 'updated' to work better and to be an income stream for the company that put said software out.

But when you have people DELIBERATELY writing needless, convoluted code in an effort to keep their job because they are the only one who can upgrade it--you have the situation we have to day which is addressed humorously by the The International Obfuscated C Code Contest

I'd note that the true function of compiled code can be obfuscated and hidden just as can source.

Yes, it's about 816 characters in total. This is complete fail compared to the kind of stuff that's done for the IOCCC competition. The 140 byte function they wrote implements once tiny part of the whole thing, and looking at it suggests that there really aren't going to be many interesting programs possible in 140 bytes of javascript.

If you want to see actually impressive tiny programs written in 2K of C code, like the guy who wrote an entire BASIC interpreter one year and then followed it up with a compiler for the same language the next year, then check out the IOCCC sinners page:

http://www.ioccc.org/years.html

G.

Efficiency should be measured in how small the number of lines of code/bug fixes are needed for implementing/maintaining the desired functionality.

You want me to minimize line count? I can do that. I'll probably follow it up by submitting the code to the IOCCC, but you'll get the small codebase you asked for.

You stretched a bit what I meant, but you do have a point
(thanks for reminding about them anyway; made me curious: are they still running the contest? Going to visit their site)

Efficiency should be measured in how small the number of lines of code/bug fixes are needed for implementing/maintaining the desired functionality.

You want me to minimize line count? I can do that. I'll probably follow it up by submitting the code to the IOCCC, but you'll get the small codebase you asked for.

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.

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.

We've all coded a quine, but this goes at least three steps further. Documentation here.

I am so looking forward to reading the 2012 winning entries!

We've all coded a quine, but this goes at least three steps further. Documentation here.

I am so looking forward to reading the 2012 winning entries!

> I should know, I won the IOCCC years ago, and used it many times in my resume.

Odd. There is no Rosco P. Coltrane listed on the winners page: http://www.ioccc.org/winners.html

Either you lied, your name isn't Rosco P. Coltrane or you were an anonymous submitter.

The key power C macros had over any Template-type construct I've seen is that you can actually paste the name of the macro arguments to form unique variable names within the macro. So a single macro could expand to three or four different functions, a handful of variables, etc.

Yes, people are prone to hanging themselves by abusing macros, but you can do some wicked code simplification that expands inline to maximize performance. I had macros in my library of useful stuff that turned all the declarations and accessors of a "attribute and methods" into a single macro invocation. It was hard to debug them initially, but I used them for years afterwards without problems.

Sorry but reading this gives me shudders. Read some winning entries in the The International Obfuscated C Code Contest to see why some 'features' of C are like a disease. One just has to love the Biggar entry beautiful abuse of the C macro system.

The key power C macros had over any Template-type construct I've seen is that you can actually paste the name of the macro arguments to form unique variable names within the macro. So a single macro could expand to three or four different functions, a handful of variables, etc.

Yes, people are prone to hanging themselves by abusing macros, but you can do some wicked code simplification that expands inline to maximize performance. I had macros in my library of useful stuff that turned all the declarations and accessors of a "attribute and methods" into a single macro invocation. It was hard to debug them initially, but I used them for years afterwards without problems.

Sorry but reading this gives me shudders. Read some winning entries in the The International Obfuscated C Code Contest to see why some 'features' of C are like a disease. One just has to love the Biggar entry beautiful abuse of the C macro system.

I've never understood this argument. Poor programmers can write unmaintainable code in any language, including C. If we judged the maintainability of each language on the worst examples we could find they would all be terrible.

A few things I couldn't seem to work in to this reply:

1) Forth also crossed my mind in the course of this discussion. You may be interested in an old IOCCC entry called "First and Third Almost Forth" http://www.ioccc.org/1992/buzzard.2.design

2) When you write "it doesn't mean we can't produce a program which, when actually run ... doesn't produce understanding." I get the impression that you think that C1 has much broader implications than Searle intended. I'd like to clarify that the CRA is in no way an argument against the production of artificial minds in general -- only to a specific approach to their production.

3) When you write "in many cases the meaning is defined in terms of the meanings it ascribes to the program it's using." I think we can get to this in a discussion of A3. For now, suffice it to say that any such semantic would exist only within the context of the extrinsic semantics already applied to the formal system. (Think of it as a derived semantic [my term, sorry] -- this is how I got to thinking about Forth -- anyway, it would remain extrinsic as it only gets its meaning by virtue of the extrinsic semantics applied to the syntactic statement of which it is composed.)

Ok, I'll accept that a program, by itself, has no meaning except that which is applied to it. If that is true, then obviously a program by itself (this is a really strong restriction) can't produce understanding

A1 doesn't even ask you to go that far, only to accept that programs are purely syntactic. If you accept your stronger statement, I think we can both agree to A1, with your restriction fully in place.

I have some issues with what A2 actually means, but that's a definitional issue. It may be relevant if you want to argue that the meaning a simple circuit ascribes to a switch being off is or is not a mental content of that circuit. But that's just devolving to silliness...

I agree. Though I will point out that all A2 says about the nature of minds is that they have "mental contents" (a terrible choice of words.) This is easy to agree to, for those possessed of mind. As I punned before, it seems "self evident".

A3 is the most contentious point, and gets both the least and most attention (I explain this below). I'll restate it here, just for clarity.

A3: Syntax by itself is neither constitutive of nor sufficient for semantics.

This deals neither with programs nor minds, which is a great relief . When I first read it years ago, I found it at once both obvious and insightful. I don't know if you agree to this or not, so I'll not go too far with it.

According to Searle, A3 is the point he intended to make with the Chinese Room illustration. Had he made this statement in 1980 (or directly in 1984) instead of ten years later, he could have saved everyone a lot of trouble!

I don't think the Chinese room actually corresponds to A3.

(I don't mean to pull this out of context, but I couldn't decide if it went more with the sentence above or below.)

I'll be the first to admit that it is, quite possibly, the worst way to illustrate A3 ever. It worked for him, but he knew what he intended before he wrote it!

Some of the problems you raise in your earlier post, for example, I will readily agree are valid within the context of the illustration, but don't really address A3. The CR illustration can easily appear unrelated to the argument he intended to make. (It hurts far more than it helps). I can agree with you on that point, or at least say that I understand your perspective here. It's one of the reasons I prefer to focus on the axioms rather than the illustration -- it's too easy to get distracted by irrelevant details.

Most of the arguments you see against the CRA focus exclusively on the illustration, and not his axioms. (This is what I meant when I said that A3 is both the mos

Bugs are often not obvious. As someone else pointed out above, the code may even look perfectly fine but can still exploit compiler quirks. Also, look at at http://www.ioccc.org/

There is a difference between complicated and expressive.

C++ is complicated. C is expressive. It's no coincidence that C used to have the same reputation as Perl for having too many ways to skin the same cat, hard core geek appeal, and obtuse, punctuation-heavy syntax (witness the IOCCC).

C

Perl

Python

Ruby

From the 2004 International Obfuscated C Code Contest!

From the 2004 International Obfuscated C Code Contest!

I think that's what the IOCCC is for.

Even small codebases can become practically incomprehensible if written with little thought given to long term maintenance.

Heck, 4KB is enough to confuse me.

To answer your first question, you're partially correct that a debugger can do wonders to highlight malicious code. Of course, as you point out, knowing when and where to use a debugger can be a little challenging. And then the realization that unless exceptional care is taken, the code you're stepping though might not even contain or reveal the exploit. (Since the mere act of viewing the byte code in a debugger can change affect it's operation.) There's one story that really opened my eyes to the possibilities. I don't remember where the long beards keep the real link, but this seems to be the story I remember:

http://cm.bell-labs.com/who/ken/trust.html

This was the first story of real high level obfuscation I learned about in college. As a result of Ken Thompson's little speech here, he caused the DOD to change the way they do code reviews to catch back doors like this. And the obfuscated C challenges have been going on since at least the early 80s. Some of the winners are real treasure troves of high level trickery.

http://www.ioccc.org/years.html

IOCC rocks!

korn.c is a good example, probably one of the best one-liner programs I have seen.

The International Obfuscated C Code Contest.
If anyone can do something underhanded and make it compile it is a C programmer.
Of course if VB was an actual programming language you could say the same thing.

You mean the GNU Project's definition of free software is clear on this. Not everyone agrees with their definitions.

Even on the GNU Project page that you link to, they never satisfactorily explain why source code is required for it to be considered free. They say that access to the source is required for you to "study how the program works [...] change it to make it do what you wish [...] improve the program, and release your improvements", but this is just flat out untrue. Custom made patches allow you to do both of these things, and there are numerous tools available to facilitate this; debuggers, decompilers, etc. etc.

The source code "requirement" really feels like a totally artificial addition to the entire definition, and I would say it even goes against the spirit of the idea behind Free Software - it imposes conditions upon the original coder that may not be reasonable, or even be possible: Hard drive crashes, death, or other catastrophes may cause the source code to be lost forever - but if a binary of the program still exists, and the author's intent for it to have a Free Software license is clear, why would anyone who truly believes in the concept of Free Software deny that it is Free?

The source code requirement does not even make sense in some situations; a hand-coded binary does not have any source code! According to their definition, the person writing such code would have to translate their binary into some programming language - this forcible translation makes both extra work for the programmer, and creates an inefficient (and largely pointless) version of the software.

The GNU Project's definitions betray their blind dogmatism - they have decided upon an entirely arbitrary definition and declared that it is a 100% requirement to use the term in this way ... and it is a way that is pointlessly exclusionary. After all, what is source code other than an easier-to-read representation of the resulting binary? For that matter, what is a binary other than a translation of the source language (meant for one audience - humans) into a different language meant for another audience (processors)? Any differentiation between binary language and a programming language is an arbitrary one; there are many, many programming languages that run the gamut from being almost-binary (e.g. assembly) to being almost-natural (e.g. COBOL). Declaring that any such arbitrary limitation is required is absurd - it would make as much sense to claim that it's not free software unless it's written in a coding language based on one of the romance languages, or written using an ISO character encoding.
(Just to head one counter argument off, namely the intended level of human readability: Binaries are not meant to be understood by humans, but source code is, and that is the difference? Well then, I guess none of this software (all written in C) can ever be considered Free Software?)

So long as the program is available for free, does not limit your use of it, allows you to make whatever changes you want to it, and allows redistribution with or without modifications, I (and most people) would consider it Free Software. Source code should be considered a heavily-encouraged option, not a requirement. (Clarification note: I do agree that free licenses should be allowed to require those who modify the code to include the modified code when they redistribute. I just don't believe that a license that doesn't require source code should be automatically disqualified from being considered Free.)

We make with C, no problem.

Yes! I look forward to him winning The International Obfuscated C Code Contest. Now THAT's a real challenge for any programmer. And so much more fun for the spectators.

Like that?

main(O){int I,Q,l=O;if(I=l*4){l=6;if(l>5)l+=Q-8?l-(Q=getchar()-2)%2:l;if(Q*=2)O+="has dirtiest IF"[(I/-Q&12)-l/Q%4];}printf("%d\n",8+O%4);}

(Came from kopczynski.c, at http://www0.us.ioccc.org/years.html)

Sounds like an imperative programmer talking: you 'use' the sort. As if it is a certain step in a program, instead of something that can be interleaved with other calculations.

You're very wrong. An imperative programmer "invokes" or "runs" the sort. A functional programmer "uses" its result in another computation. The latter is entirely consistent with FP paradigm.

On a side note, if you're doing a sort but not using its output - regardless of lazyness/eagerness of the language - then why you're doing it in the first place? In pure FP language such as Haskell it's even more visible, since you essentially forcibly ignore the result of a function you call, and there are no side-effects - so you very clearly tell the compiler to "do nothing". And why would you explicitly write "do nothing" in your program (unless you're coding in Nil)? But it is exactly what the Shootout guys did.

As a related anecdote, the IOCCC guys have once got a technical winner - the shortest C program possible that produced itself as its output. It was a blank .c file (and a makefile that just renamed and chmod+x it so it becomes a do-nothing binary). It was a valid entry by the existing rules... but it forced the rule change afterwards, and for a good reason.

Sounds like an imperative programmer talking: you 'use' the sort. As if it is a certain step in a program, instead of something that can be interleaved with other calculations.

You're very wrong. An imperative programmer "invokes" or "runs" the sort. A functional programmer "uses" its result in another computation. The latter is entirely consistent with FP paradigm.

On a side note, if you're doing a sort but not using its output - regardless of lazyness/eagerness of the language - then why you're doing it in the first place? In pure FP language such as Haskell it's even more visible, since you essentially forcibly ignore the result of a function you call, and there are no side-effects - so you very clearly tell the compiler to "do nothing". And why would you explicitly write "do nothing" in your program (unless you're coding in Nil)? But it is exactly what the Shootout guys did.

As a related anecdote, the IOCCC guys have once got a technical winner - the shortest C program possible that produced itself as its output. It was a blank .c file (and a makefile that just renamed and chmod+x it so it becomes a do-nothing binary). It was a valid entry by the existing rules... but it forced the rule change afterwards, and for a good reason.

The IOCCC judges can be contacted by following these instructions. If you want to contribute your expertise or time to the IOCCC then please contact us.

My favorite is this one:

http://www.ioccc.org/1996/eldby.c

But modern terminals are too fast for it :)

ioccc

Bonus points will be awarded if they submit the code in Perl, Assembly, or FORTRAN.

Bonus points if the same source works in 3 or more languages, see http://www0.us.ioccc.org/1986/applin.c

Along with the ? : ternary opp.

Code that is hard to read means job security.

The IOCCC is a good place to learn style.

Sql Injection is a good thing. You don't need to escape user data before send it to the DB, users never do anything bad.

(Go ahead and mod me troll, I can take the hit. Note that this is actually a list of things NOT to do. Except goto is sometimes useful, for breaking out of a few layers of loops/blocks.)

My personal favorite for C coding artwork

I don't code no more! I have enough trouble speaking Englisch!

Still - there is a general failure on a higher level where there are expectations that systems written entirely out of script languages are better than systems written in a compiling language. It may work from the beginning, but as soon as maintenance starts on the system there will sooner or later be problems. Especially if you have different people doing the maintenance compared to the people developing.

What are you trying to say? Are you saying that maintenance on a system written in a "scripting language" will cause problems, but if the system was written in a "compiled language", then maintenance won't cause any problems? Do you think that it's easier for a person to read code they didn't write if it's written in a compiled language as opposed to a scripting language? Have you ever heard of the International Obfuscated C Code Contest? How is it possible to write obfuscated code in a compiled language?

Why do you think it's a "general failure" if systems written in a scripting language are better than those written in a compiled language? Wouldn't it make sense that the best systems are written in the most powerful languages, regardless of whether the language is compiled or interpreted? Did you know that some languages such as Lisp and Perl can be compiled or interpreted, depending on what the user prefers?

It's not IE, it's the Java plugin (which, umm, MS doesn't even make anymore). It's just a normal cross-origin vulnerability.

(Umm, this is my best guess, but I believe it makes sense and not surprising.)

GIF files have a header (GIF89a and all). JAR (PKZIP) files have a footer (central directory, i.e. the TOC). When the attacker uploads the file, the server sees the GIF (/PNG/JPEG/BMP/...) header and accepts it as an image. Anybody going to the server's page would have their browser attempt to load the file as an image (and possibly succeed, if the attacker wanted it).

The Java plugin would be invoked by a page on a completely separate sever (that the attacker controls), with an <object> / <applet> tag. The plugin would load from the attacked server (e.g. facebook), and therefore for origin checking purposes it belongs to the attacked server.

It's like this old IOCCC entry which happens to be a shell script, a makefile, and C source all at the same time.

People have been doing similar things as weak stenography already - posting images which have been concatenated with archives (rar, zip) that show as images in the browser, but the archivers would search through the whole file for something to extract.

http://www.ioccc.org/2004/anonymous.c
http://www.ioccc.org/2004/anonymous.hint
 

http://www.ioccc.org/2004/anonymous.c
http://www.ioccc.org/2004/anonymous.hint
 

Use uber obfuscated code: Example: #define w "Hk~HdA=Jk|Jk~LSyL[{M[wMcxNksNss:" http://www0.us.ioccc.org/years.html

My code is only cryptic if it's submitted to a contest like this one: http://www.ioccc.org/ or if performance is critical.

This day and age, the few extra cycles to do something in a more readable fashion are worth it for most tasks. If performance is critical, those rules are out the window and it can get pretty hairy. But those are also the times when you write novels for your comments to let others know what's going on and why it was done.

Layne

Ah IOCCC, my favorite entry in the quine category (a circular quine) http://www.ioccc.org/2000/dhyang.c

Oh, really?

This example is code that works and also has some nice quality attributes: 96% of the program lines (631 out of the 658) are comment text rendering the program readable and understandable. With the exception of the two include file names (needed for a warning-free compile) the program passes the standard Unix spell checker without any errors.

This example is also code that works, and is quite compact for what it achieves.

I don't consider any of the two examples quality code. And sprucing bad code with object orientation, design patterns, and a layered architecture will not magically increase its quality. On the other hand, you can often (but now always) recognize bad quality code by looking at figures one can obtain automatically. If the code is full of global variables, gotos, huge functions, copy-pasted elements, meaningless identifier names, and automatically generated template comments, you can be pretty sure that its quality is abysmal.

This example is code that works and also has some nice quality attributes: 96% of the program lines (631 out of the 658) are comment text rendering the program readable and understandable. With the exception of the two include file names (needed for a warning-free compile) the program passes the standard Unix spell checker without any errors.

This example is also code that works, and is quite compact for what it achieves.

I don't consider any of the two examples quality code. And sprucing bad code with object orientation, design patterns, and a layered architecture will not magically increase its quality. On the other hand, you can often (but now always) recognize bad quality code by looking at figures one can obtain automatically. If the code is full of global variables, gotos, huge functions, copy-pasted elements, meaningless identifier names, and automatically generated template comments, you can be pretty sure that its quality is abysmal.

I guess the Internation Obfuscated Ada Code Competition is a non-starter then.
(Notes that ioacc.org is unregistered)
Compare IOCCC

There used to be an Obfuscated Perl Contest (in the spirit of the International Obfuscated C Code Contest). I suspect that the reason they stopped holding the contest is because of the risk of someone inadvertently causing a universe-collapsing paradox with their contest entry.

I think an analogy to programming styles is appropriate here. Clever code is often lauded, just because so-and-so managed to write a one-liner that does . People compete to be clever (see those obfuscated C contests). Clever is impressive.

But obvious stuff like writing easy-to-understand, well-documented code... that's just expected, no matter how hard it is to do in practice.

Pretty? This one even spells out IOCCC.
http://www0.us.ioccc.org/2004/newbern.c