== An extreme example of C preprocessor (ab)use A while back, [[thedailywtf.com http://www.thedailywtf.com/]] ran [[this entry http://thedailywtf.com/forums/60255/ShowPost.aspx]] on C preprocessor abuse. Unfortunately (and in fact as noted in the comments), this is nothing to the true devotee of turning C into a different language. This preprocessor trail was blazed early on, in the V7 Bourne shell, written by Steve Bourne. The story goes that Bourne didn't really like C all that much, and instead much preferred Algol. Armed with the new C preprocessor he saw the opportunity to fix this problem and created what later generations would come to call 'Bournegol'. For a long time this could only be properly appreciated by people with a V7 source license. These days, [[tuhs.org http://www.tuhs.org]] has changed all that, so I can show you this 100% genuine typical excerpt (taken from [[cmd.c http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/cmd.c.html]]): LOCAL VOID prsym(sym) { IF sym&SYMFLG THEN REG SYSPTR sp=reserved; WHILE sp->sysval ANDF sp->sysval!=sym DO sp++ OD prs(sp->sysnam); ELIF sym==EOFSYM THEN prs(endoffile); ELSE IF sym&SYMREP THEN prc(sym) FI IF sym==NL THEN prs("newline"); ELSE prc(sym); FI FI } (I have changed the original tab-based indentation to four spaces, so that this fits better on your screen.) The Bourne shell was also infamous for its clever approach to memory allocation, where it didn't so much allocate memory as use it and wait for the SIGSEGVs to come rolling in as a sign that it should expand the process's memory with _setbrk()_. One result of this was that _sh_ served as an excellent stress test for a new Unix port's signal handling; another was that if you hit a real SIGSEGV due to a Bourne shell bug (and there were a few), you (eventually) got an error message about being out of memory instead of anything useful like a core dump.