Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Classic Computer Science Papers

sengan posted more than 15 years ago | from the things-to-reread dept.

Technology 54

Dean Chouinard writes "For inspiration I occasionally peruse the web pages of Dennis Ritchie, Brian Kernighan and Ken Thompson. I recently found a pointer to the following classic paper by Ken Thompson. Other interesting papers are listed under the classics directory as well."

cancel ×


Sorry! There are no comments related to the filter you selected.

quickie (0)

Anonymous Coward | more than 15 years ago | (#2036898)

Isn't this kind of thing what the Quickies are for?

Jason Eric Pierce

Goto... (0)

Anonymous Coward | more than 15 years ago | (#2036899)

Just looking through there real quick makes me want to say


nah, nah, nah

Question (0)

Anonymous Coward | more than 15 years ago | (#2036900)

There just isn't much you can do if you're using any software that you didn't write yourself, including a compiler. You download a binary compiler and you're potentially screwed. Even if you build a compiler from source using a binary compiler, you're still potentially screwed. It's too hard to do a disassembly and verify that the executable isn't going to do something you don't want it to. But certainly you'd feel a lot safer if you had the source available; at least it would let you detect less subtle back doors.

Possibly in B, or in assembly, or by hand in 0&1's (0)

Anonymous Coward | more than 15 years ago | (#2036901)

If you're really interested in this, Andrew Tanenbaum (the guy who wrote Minix, which is what Linus Torvalds built Linux from) wrote a book about this sort of thing, called "Structured Computer Organization." If you *really* want to know about how the first compiler was built, get ahold of the transcript for the History of Programming Languages conference held to honor the 25th anniversery of the ACM, sometime in the 70s.
The keynote speaker was Admiral Grace Hopper; she wrote the first compiler and, in the speech, goes step-by-step on how she built it.


Hold on. ACM sucks dick. (0)

Anonymous Coward | more than 15 years ago | (#2036902)

Maybe your not ACM stuff.. Buy the way you wrote that posting.. i have more than assumed what i just said above.. good riddence..

I think you guys missed the point (0)

Anonymous Coward | more than 15 years ago | (#2036903)

The point of this article is that it is very easy to embed an undetectable trojan horse in any program-handling program such as compilers, assemblers, loaders or hardware microcode.

"No amount of source-level verification or scrutiny will protect you from using untrusted code."

In other words, any publicly available and modifiable source code such as Linux is subject to this kind of attack. And the worst part is that even if a person double-checks modified code from someone else, it is impossible (even to Ken Thompson) to see all the side-effects (Trojan Horse attacks) that may be included with code changes.

eek (0)

Anonymous Coward | more than 15 years ago | (#2036904)

That we can find ourselves getting our hands dirty with the stuff of evolution when we do computers is one of the most intellectually satisfying things about it.

. . . i usually describe that phenomenon as "vertigo", or "the great fear" :) probably if i ground my poor little brain to a fine powder learning assembler and/or writing a (simple!) compiler i'd feel better about the whole thing . . . aside from the inherent coolness value of doing that stuff, which is sufficient justification in itself. this, i assume, is one reason why people don't regret having CS degrees.

I almost agree. (0)

Anonymous Coward | more than 15 years ago | (#2036905)

I had a paper published in one of the SIG proceedings, my boss reviews for the SIG (though not our own papers, of course), and none of that brought me (or her, for that matter) any cash. However, when the library's copy of one of the proceedings went missing, I had to fork over $20 to download an article from it.

Free Software, Open Source, and impeding access to new research.... Which one seems out of place?

Maybe I'll try to convince folks at work we should patent the next thing we come up with...

Evolution works just this way (0)

Anonymous Coward | more than 15 years ago | (#2036906)

Isn't it funny how all this evolution takes so
much thought from the "creator"? :-)

rip Science (0)

Anonymous Coward | more than 15 years ago | (#2036907)

there are those who are professing that the age of Science is ending...

a dearth of new scientific papers lends credence to this belief...

Atheists, get you to your closets!

this is ACM classics, not "comp sci classics" (0)

Anonymous Coward | more than 15 years ago | (#2036908)

there is a big difference. i dont think
Alan Turing ever published anything in the ACM
did he? well his two big papers werent. they
were in the Journal of the London Mathematical Society (turing machines)
and in Mind (AI + turing test + etc) (a *philosophy* journal, hear that u geek wankers?)

since the acm didnt publish it i doubt it will show up there on their pages.
due to copyrights laws, alot of the best Computer Science stuff is on those dirty dusty old shelf things
sitting in large block buildings on university campuses (most publicly accessible tho)

You Confused Your Operators, Baby (0)

Anonymous Coward | more than 15 years ago | (#2036909)

I would think that ACM classics are a SUBSET of COMP SCI classics and are of course a member of that set. Dont sweat it.



preincrement vs postincrement (0)

Anonymous Coward | more than 15 years ago | (#2036910)

C = ++B increments B before the assignment... so C == B

C = B++ increments B after the assignment, so B > C.

(assuming B doesn't overflow, of course...)


Hold on. ACM sucks dick. (0)

Anonymous Coward | more than 15 years ago | (#2036911)

The authors of the ACM Classics recieved no compensation for their articles and letters to the editor. While ACM might have paid the peer reviewer of the article a small sum I doubt it. The ACM does not owe me anything, but I would rather in the future that authors just put their articles up on something like the e-print archive [] because I feel that the benefits of anyone being able to download computer-science articles without toll outweighs whatever benefits the ACM provides. So, yeah, I guess I agree that ACM does suck dick a lot of the time as far as I can tell.

I agree: Djikstra IS THE MAN! (0)

Anonymous Coward | more than 15 years ago | (#2036912)

Semper floreat and crescat Mathematics Incorporated!

Chickens & Eggs & Real Programmers (0)

Anonymous Coward | more than 15 years ago | (#2036913)

Real Programmers use cat>progname

No Compiler (0)

Anonymous Coward | more than 15 years ago | (#2036914)

I did 6502 on the Ataris, but what got me hooked on assembler was a BASIC program on the Commodore PET called "Sink the Sub". When your depth charge hit the sub, the screen would flash using reverse video. When we saw that, my friends and I just *HAD* to figure out how they flashed the screen so quickly.

It wasn't long before the "Sink the Sub-Routine" as we called it, was appearing in several programs. I started writing in assembler shortly after, but gave up on it. After all, all I had to work with was a two pass assembler running off of a casette tape. I could hand assemble faster than that thing. Oh yes, the good old days.

sort of kind of an answer, but not really (1)

Anonymous Coward | more than 15 years ago | (#2036915)

This sounds like the kind of 'warning' that could be leveled at the open source process,

having read the article (and enjoyed it immensely), i don't see how free software would be more vulnerable than any other variety. it's transmitted from binary to binary, after having been initially incubated in the source.

actually, the great thing about this would have been if it had scared people into compiling their compilers back and forth among other vendor's compilers and their own. i think (unless i'm as confused as i think i am!) that would tend to kill it. or else would it just tend to add any *other* trojan things that the others might have? you know what, i think it would be the latter. never mind. i've never heard of anybody doing that, but then again i wouldn't have heard of it if they had, so who knows.

if there's anybody out there who doesn't get an attack of vertigo contemplating the code in question, please chime in!

what would a "cure" be? maybe bootstrapping writing an assembler by hand, byte by byte, and then writing a minimal c compiler in assembler . . . ? i know almost nothing about assembly language or whatnot, though i did see somebody once write a trivial (REAL trivial!) program by typing opcodes or whatever you call them into the dos debug.exe thing. it seemed kinda like the long way around, for most purposes, but you could avoid introducing anything weird if you really wanted to. you shouldn't trust debug.exe, but it would be trivial to write a quick minimal write-only binary editor in c, the output of which could be verified. god, this is like a philip k. dick novel.


Rice's Theorem (1)

Anonymous Coward | more than 15 years ago | (#2036916)

Trojan horse code *can't* be detected, at least not by a computer program. The only way to do it would be for a human to go through each line of code at every level, and even then you can't always be sure.

It's not that complex. (1)

Anonymous Coward | more than 15 years ago | (#2036917)

They were writing programs long before compilers were invented. They wrote them in machine code or assembly if they were lucky enough to have an assembler, which isn't too hard to make.

Then, once you have a couple compilers you write other compilers with those existing compilers. The 'test' seems to be writing a compiler that can then be used to compile itself. GCC does this, it has some stub code that can get you a basic compiler and it uses that to compile GCC and then you can redo the whole thing with GCC.

Take a compilers course, I think it was the hardest course I took in college but you learn a ton. It's not too tough to build a very primitive 'yacc compiler' that takes a yacc grammer and outputs assembly for a very simple language. If you assume the first compilers were something like that (and they were) then you suddenyl have a better tool to make an even more sophisticated compiler, and this sprials and spirals and you eventually end up with modern compilers.

First Compiler (1)

Anonymous Coward | more than 15 years ago | (#2036918)

AFAIK all the early compilers (COBOL, FORTRAN, etc) were written in assembly. I think C was originally written in B (which was derived/inspired from BCPL, sortof a high-level assembler, designed for writing operating systems). In a way, you could say that C = B++.

Some of the most important things you'll read (1)

Anonymous Coward | more than 15 years ago | (#2036919)

These are some very important pieces. I remember reading them in college. I felt like I was getting into their brains - no watered down texts that give only the greatests ideas in clean form.

Who knows. Someone reading them for the first time because of an introduction on here might be inspired to advance the field of knowledge.

Sure beats people bragging about how many MP3 files they've pirated.

Ron Rangel

First Compiler (2)

Anonymous Coward | more than 15 years ago | (#2036920)

Hey, something I have ALWAYS wondered is how they made the first compiler? Since obviously they had nothing to compile it with. And compilers for new languages, are they made in different languages? Or what? And... if the c-compiler was written in c, how did Ken Thompson compile it the first time?


Heard this story at MIT... (3)

Anonymous Coward | more than 15 years ago | (#2036921)

My recitation instructor when I took 6.004 at MIT was Steve Ward. (This was 3 or so years ago.) Ward told us this same story. It seems that Ward and Ken Thompson went out to a bar one time, and Thompson was describing how to plant this trojan in a compiler. After a few more drinks, Thompson admitted to actually creating such a compiler, and compiling the login program with it. It worked. Ward kept feeding Thompson drinks, and pressing for more information. But Thompson would never quite say if he actually did anything with it, like if he merged it in on an install tape.

I expect Thompson didn't do anything with it; I expect he was just holding back to keep an air of mystery around it all. But still... interesting...

(That's one of my best memories of that class. All us youngins hanging on every word of Ward's story about the "real" hacking done by our heros. Or at least mine. ;)

Corolary: forking is good (1)

KMSelf (361) | more than 15 years ago | (#2036922)

This line of reasoning leads naturally to the conclusion that some forking is good. It would be a Good Thing (TM) to have at least two compilers, with a significantly different code base and provonance, to allow cross-compiling of sources, particularly compilers.

To a limited extent, at least, forking is good.

sort of kind of an answer, but not really (1)

Trepidity (597) | more than 15 years ago | (#2036923)

That would be troublesome, since the two compilers most likely won't produce identical binary output anyway, even if there are no trojans. Try compiling a program on gcc and then on cc, and then on egcs, and you'll get slightly different binaries.

Re: Hold on. ACM sucks dick. (1)

Trepidity (597) | more than 15 years ago | (#2036924)

Umm, aren't the classics on the website already free? I just read the Ken Thompson article that the article linked to, and I have no ACM subscription.

First Compiler (1)

jabbo (860) | more than 15 years ago | (#2036925)

In Forth, I believe.

A little neglected (1)

Smack (977) | more than 15 years ago | (#2036926)

Too bad they haven't updated that page in 2 1/2 years... I'm sure there are many other classics that should be up there.

I love Ritchie's biography! (1)

Smack (977) | more than 15 years ago | (#2036927)

Sample quotes:

"Subsequently, I aided Ken Thompson in creating the Unix operating system."

"Early in the development of Unix, I added data types and new syntax to Thompson's B language, thus producing the new language C."

Imagine having that on your resume! :)

I think you guys missed the point (1)

Frater 219 (1455) | more than 15 years ago | (#2036928)

gcc was first compiled with a non-gcc compiler, which could not have known how to infect gcc, because gcc hadn't existed when the previous compiler was written.

Since then, gcc has always been compiled using gcc, and its source has been open for public inspection. egcs has also been compiled from gcc and egcs versions which are also publicly inspected.

The proof that publicly-inspected versions of gcc and egcs are not infected follows via recursive proof. G(0) is clean, because it was compiled with a non-gcc compiler; G(n+1) is clean if G(n) is clean, because its source is publicly inspected. Hence G(n) is clean for all n.

The problem enters when a version of gcc or egcs is **secretly** forked from the main (publicly inspectable) source tree, and *its* code is contaminated, and it is then distributed in binary form, as if it were legitimate. Once binaries enter the arena from an unverifiable source, you have a problem, since if anyone compiles a (clean-source) version of gcc with an infected compiler, they only get infected compilers as a result.


* Maintain a "reference compiler binary" for each platform, located at FSF or CYGNUS. This would be a copy of gcc or egcs which had been derived from an old (pre-gcc) compiler, and which was thus known (by the above recursive proof) to be clean.

* Trace through all compilers with a debugger. While it's possible that a debugger could be hacked to skip over the trojan routines, it would be MUCH harder to hide than the largely black-box process of compilation.

An analogy:

Every newly-compiled compiler has two "parents": its own source code, and the compiler which was used to compile it. Infection is a dominant genetic trait: if *either* parent is infected, then the "baby" compiler will be infected too.

If you detect an infection in a compiler (by stepping through it with a debugger, for instance) then you know that one or both of its parents were themselves infected. This could theoretically be used to trace an infection back to the source patch that introduced it.

segfault (0)

dalke (1472) | more than 15 years ago | (#2036929)

I'll just take it as coincidence that this Slashdot article appeared a few days after my Segfault "news" article [] on the same subject.

segfault (1)

dalke (1472) | more than 15 years ago | (#2036930)

It was a coincidence.

Thanks for the verification :)

if this is the type of stuff on segfault I will certainly be checking it out from now on.

For the most part, no, it isn't.

The method is regexp dependant... (1)

RobotSlave (1780) | more than 15 years ago | (#2036931)

The method described depends on regular expressions in general, and on recognizing particualr functions to be compiled in particular. You could do a bit to foil this sort of scheme with the judicious use of sed-- eliminate comments, rename all functions, variables, and macros, salt what's left with whitespace, and rename all files and change your makefiles accordingly. Then compile and rename your executables. It should be very easy to automate this in several different ways-- perl, shell scripts, etc.

This would make it very difficult to produce a trojan that could replace a specific function in a specific program *without* affecting other programs to be compiled.

It is still possible to insert a trojan that will be added to *every* binary compiled, but checking for this is trivial-- the expected machine code for, e.g., hello world can be calculated by hand and compared to the output of your compiler.

Code munging is only a partial protection, probably less effective than bootstrapping, but it would at least give the crackers some headaches.

True. (1)

RobotSlave (1780) | more than 15 years ago | (#2036932)

The method is only a hindrance, not a panacea, even if the method is only applied to source code. I think I tried to stress that.

Machine-code trojans would tend to be platform dependant, and would be much harder to implement, especially for a portable, cross-compiling compiler such as gcc.

I assume that by a "machine code implementation" yo mean a trojan that would wait until code had been compiled, and then examine the resultant bits for a particular pattern to replace.

Small changes to the source code could result in such large changes to the object code that this method would only be practical for infecting code that is not expected to change. The exuberant code munger could randomly salt the code with valid but useless statements-- printing to /dev/null, sending a packet to the loopback, etc., that could not be optimised out. This unseemly bloat would monkeywrench trojans expecting a nice predictable chunk of machine code. Going through many generations of this before generating a binary with no "extras" would reduce a trojan's chances of survival.

The problem of recognizing a particular function in a particular program in machine code for many different platforms is on a par with recognizing a particular function in a particular program in source code with arbitrary function/variable/file names. It is certainly soluble, but much more difficult than the example put forward in the paper.

I stand by the assertion that munging would make life harder for the cracker.

Not forking-- multiple implementations. (1)

Chris Mikkelson (2363) | more than 15 years ago | (#2036933)

Yep, like gcc, lcc, and TenDRA....

But what do you compile *them* with ;-)

Cross-compile all the way down, baby (2)

jonabbey (2498) | more than 15 years ago | (#2036934)

Once you have any computer with the ability to run code, you can simply write code on that system to build the first compiler on another system, then copy that compiler over to the new system and go from there. Once you have a working code environment on any system, you'd be crazy not to use it to develop the tools for the next.

Cross-compile all the way down, baby (2)

jonabbey (2498) | more than 15 years ago | (#2036935)

Well, of course it does. I didn't literally mean
'compiler' in the sense of gcc, I meant all the bits that is required to get a new computer system able to reasonably support its own code development.

A classic example of poor web maintenance, too (1)

judd (3212) | more than 15 years ago | (#2036936)

The sad thing is there don't seem to have been any updates since mid-1996. Don't you hate continuing series that don't?

I guess the ACM don't care about their website that much. (And they're using the CERN webserver still!)

Djikstra (1)

Mark Storer (4097) | more than 15 years ago | (#2036937)

It's (vaguely) interesting to note that Djikstra is the only author with two papers in their list.

So there.

"Umm... Goto's are bad, m'kay?"

Actually, I've been hunting around for the "Goto's" paper for a while now.

Question (2)

Skip666Kent (4128) | more than 15 years ago | (#2036938)

I'm a little beyond the 'hello world' stage of programming, but not much. Can anyone tell me how far along developers have/have not come in terms of detecting the type of 'trojan' code discussed in this paper?

This sounds like the kind of 'warning' that could be leveled at the open source process, and I'd like to be able to refute it as accurately as possible.

First Compiler (2)

wilhelm (5091) | more than 15 years ago | (#2036939)

They wrote it in assembly language, or raw opcodes, just like most everything else they did back then.

Supposedly that's one of the big tests of the viability of a language: whether you can write a compiler for the language in the language. But you've always gotta write the first compiler in some other language.

After taking my compiler design course, I've never looked at programming the same way. Same with assembly programming. IMNSHO, every programmer should be exposed to both of these topics.

Question (1)

Ed Avis (5917) | more than 15 years ago | (#2036940)

Well, it would be technically very difficult to insert such a trojan into GCC. Particularly as there are many people who 'bootstrap' GCC by compiling it with another compiler, for example, the Sun C++ compiler. If you wanted to insert nefarious code like this, apart from the problem of making it work and knowing when to trigger it, you'd have to add it to every compiler under the sun. (no pun intended.)

Not exactly news (0)

ruud (7631) | more than 15 years ago | (#2036941)

Those classic ACM papers are really interesting, but they have been on the ACM site for over 2 years now.

No Compiler (1)

korpiq (8532) | more than 15 years ago | (#2036942)

Hiihaa, I'm beginning to feel myself old.. too bad. I used to write raw machine code on Commodore-64 (though one had to use basic to access the memory). It took me about 4 years to get to the level of structured programming :) Yes past days are golden, but I'd never want them back!

There must be quite a few of us around here?

Thanks, that is what I was trying to say (1)

Midnight Coder (8953) | more than 15 years ago | (#2036943)

Except for the bit about smoking crack.

Hold on. ACM sucks dick. (1)

Bellwether (12891) | more than 15 years ago | (#2036944)

Wait a sec...The ACM is a professional organization. They offer really great services, including reduced fees to conferences, SIG memberships, etc. The prices they charge are very reasonable for the services they offer. I'm a member of SIGOPS, and SIGLINK, and SIGART -- I receive valuable publications, as well as being allowed to access their full text archives. Just because they charge a reasonable fee to allow access to their archives, they don't "suck dick."

Should a professional organization like the ACM provide free access to their archives? Why?

Chickens & Eggs (1)

DHartung (13689) | more than 15 years ago | (#2036945)

The key, Confused, is remembering that compilers are only needed for High-Level Languages. C needs a compiler, but assembler code does not. An assembler development program is merely a convenience. Most assembler code used to be hand-written (just as, before that, most punch-card code was). From this evolved the "macro assembler" which let you write out subroutines and such as abbreviations, and from that evolved high-level languages such as B, which was the precursor to C.

An interpreter is another way to start (1)

Roy Ward (14216) | more than 15 years ago | (#2036946)

When I wrote my language ReWrite, I had the problem that there were no existing implementations (Mathematica(tm) was close), but _really_ wanted to write it in itself, because compiling the langauge is quite complex, but it is good for writing compilers.

My solution was to write a quick and dirty hack ReWrite interpreter in Pascal, give it a sufficient subset of the language to get me started, then wrote a pretty minimal compiler in ReWrite, and interpreted the compiler to compile itself. (It took four days on my 8 MHz Mac Classic doing it in little chunks, that interpreter was really slow). Then I stopped using the interpreter and started extending the compiler.

A couple of memorable things from the development process:

I had the interpreter and compiler designed so that they could interoperate, and it was fascinating to watch the compilation rate speed up as more bits of the compiler were compiled (it would link the each compiled function in immediately, and use that in preference to the interpreted one). A gradual speed gain of about a factor of 60.

An interesting part of extending a language written in itself, particularly when it is not a standard language, is that once an extension has been added and works, I start using it in further development on the compiler. The langauge has changed enough since I started it that there is a bit of a mix of coding styles in there - some of the older code is quite hard to read when it has to work around restrictions that no longer exist. (That's why it turns out to have such an unintentionally appropriate name - every so often I rewrite a code module that has grown too old).

By the way, is ReWrite only goes on Macintoshes, is 68K code (not PowerPC), has free binaries but is not distributed with source, and hasn't been released for about three years. I would like to change all of that (except the free part) as I get more time to work on it.

Of course because it only goes on one platform and is wrtten in itself, to only sensible way to port it is to write a cross-compiler, ReWrite to C++ or ReWrite to Java Bytecode compiler (these last two are possible, but hard).

I've strayed off topic a bit, but my experience is that going through that process of getting a compiler going is fun, even if _everyone_ you mention it to before you get it working starts out by saying that it is a waste of time.

I've also get ReWrite on my CV, and I remember going for a job interview where the fact that I had designed and implemented language was seen quite favourably, but:

Interviewer: "What did you write it in?"
Me: "ReWrite"
Interviewer: "No, what did you _write_ it in?"
Me: "ReWrite, it's written in itself"
Interviewer: "No, what did you _write_ it in?"
Me: "The source code for ReWrite is written in ReWrite itself, just like C compilers are written in C"
(snipped a couple more ways of me trying to say the same thing in different ways)
Me: (not wanting the interview to be stuck any longer) "The user interface is written in Pascal"
Interviewer: "Ah". (he was happy then)

Roy Ward.

Djikstra IS THE MAN! (1)

phred (14852) | more than 15 years ago | (#2036947)

Maybe I should revise and post the article I wrote nearly two years ago called "Solutions Considered Harmful" which was written partly in homage to Dijkstra's famed ACM paper and partly in shock horror to the reality of what Windows 95 has done to computing.

The essence of my paper is that in a computer industry mad to sell boxes -- whether hardware or software -- solutions are merely a problem's way of creating another problem.

Truths about the old guys.. (2)

rje (15052) | more than 15 years ago | (#2036948)

I actually work with Denis, Ken, and Brian and they're still cranking out some really cool stuff. None of it is mainstream due to Lucent's (Bell Labs) marketing of it and the huge installed base of current poop (MS Win) and software (*NIX)..

True that GOTOs are still running amuck in their code sometimes. Some of their newer stuff, papers, and such should be public like the theories behind OSs like Plan9 and Inferno, two OSs based completely on a file stucture for everything.

If you check out [] you can find them and some off their recent work. Check it out.

Question (1)

Jonathan White (15086) | more than 15 years ago | (#2036949)

No, remember what you are doing when you program, you are giving a series of instructions. For convenience those instructions are written in a human readable format then later translated to a machine readable format. The actual intent of the instruction has not changed, just the representation. The trojan lies in the instruction you gave the original program (in this case gcc). When you use Sun's compiler to compile gcc, the instruction does not change, only its form (to the purists, this is an abstract view of an instruction, I don't want to hear opcodes mentioned :). Thus the trojan is still present.
In fact I would argue that this problem cannot be feasibly solved but merely represents a risk in trusting any person/entity.

Would a pointer to a website be &somewebsite (0)

Badfish (94662) | more than 15 years ago | (#2036950)

does this follow,
so then.
*somewebsite = my.shtml //better than ftp

NUTS!! (0)

PDG (100516) | more than 15 years ago | (#2036951)

What, are you some sort of sadist or something? If I wanted a brain hemmorage I'd ask my boss if I could 'restructure' all the code by tommorow.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>