Hacker News Reader

Comment by dark-star | Hacker News Reader

My favorite function, which some might say even made it into Windows ;-)

    waste()  /* waste space */
    {
     waste(waste(waste),waste(waste),waste(waste));
     waste(waste(waste),waste(waste),waste(waste));
     waste(waste(waste),waste(waste),waste(waste));
     waste(waste(waste),waste(waste),waste(waste));
     waste(waste(waste),waste(waste),waste(waste));
     waste(waste(waste),waste(waste),waste(waste));
     waste(waste(waste),waste(waste),waste(waste));
     waste(waste(waste),waste(waste),waste(waste));
    }

View on HN

But why? Waste (compiled) binary space? Or source code space, perhaps for early employee metrics gaming purposes?

And don't answer "to waste space of course" please. :)

There is a variable declared right before the waste space function. The 'wasted' space is statically allocated memory for the variable 'ospace' just before it.

There's nothing in that repo that says, but at a guess: old machines often had non-uniform ways to access memory, so it may have been to test that the compiler would still work if the binary grew over some threshold.

Even today's machines often have a limit as to the offset that can be included in an instruction, so a compiler will have to use different machine instructions if a branch or load/store needs a larger offset. That would be another thing that this function might be useful to test. Actually that seems more likely.

It might be instructive to compare the binary size of this function to the offset length allowed in various PDP-11 machine instructions

Yes it seems like this is something to do with hardware testing. Maybe memory or registers or something that needed just X bytes etc for overflows or something. It’s really random and the only person who would know it is the one who wrote it :)

Wild guess: it was a way to offset the location of the "main" function by an arbitrary amount of bytes. In the a.out binary format, this translates to an entry point which is not zero.

http://cm.bell-labs.co/who/dmr/primevalC.html

" A second, less noticeable, but astonishing peculiarity is the space allocation: temporary storage is allocated that deliberately overwrites the beginning of the program, smashing its initialization code to save space. The two compilers differ in the details in how they cope with this. In the earlier one, the start is found by naming a function; in the later, the start is simply taken to be 0. This indicates that the first compiler was written before we had a machine with memory mapping, so the origin of the program was not at location 0, whereas by the time of the second, we had a PDP-11 that did provide mapping. (See the Unix History paper). In one of the files (prestruct-c/c10.c) the kludgery is especially evident. "

One possible reason is to allocate a static global area. Without read-only protection of memory you could write to that area.

See my other comment.

The comment is a waste too. It could have explained why the function is doing what it does.

Reply on news.ycombinator.com