Well then blowtorch could open the executable for writing and truncate it to zero bytes. That would not be "storing data".

Yes, truncating sounds as valid as the unlink/rm file solution. But a lot depends on how you parse the challenge. You could parse the challenge to mean that any file access is forbidden. But if that is the case, I don't think it is solvable.

If your going to play word games like that, then you could also parse it it such that:
main() { printf("hello, world\n"); }
is a solution. The program only gives the output once and then it never does anything else. And as requested you must compile the program first. I see no verbage about preventing a rerun of the program.

Oh yeah, I tried this. It dies with a bus error and a dumped core. This shouldn't be happening. If Solaris is going to open a running executable for writing, then it should be able to truncate it as well. If it has to be consistent, it should either allow me to carry out any write related operation, or it should prevent me from performing any write related operation.

-Edit
I just tested this on FreeBSD (I use m-net.arbornet.org for this), and the unlink shown by Vino works, but my attempt to open the file for writing doesn't.

There are some other approaches to this. A smart perl script could call time() to get the current time. Then it would output a c program that would refuse to run after the next two seconds pass. That should be enough time to compile and run it once. After the output, the c prgram would sleep for 2 seconds to ensure that a second run is impossible. The perl script could also obtain the pid of the current login shell. The C program would refuse to run if the login shell has a different pid. The C program would output the string, sleep a few seconds, then kill the login shell. For added security these approaches could be combined.

A very creative approach. Excellent! And without touching any files!

There's a more complex way of doing it.

We could open (argv[0], O_RDONLY), then unlink(argv[0]), and then re-open open(argv[0], O_RDWR).

Like that, you could read the content of your program before it was unlinked ('cause the kernel still holds the reference upon unlink() if the file is open by any process) and write a new content after it was unlinked.

Now, from here you could go to very funny stuff like changing the ELF format on-the-fly (something like changing the .comment section) and then have something on your file that says "if the .comment section has a certain sha1 hash that matches whatever, the program should run, otherwise it won't run". Be aware that someone could strip the comment section very easily lol.

Another way would also be very funny like creating an assembly program that just makes your program exit, then, extracting the hex opcodes (machine-language) of that program using something like objdump and injecting those opcodes on your other program's main function. Of course you would have to know the right offset to mmap() to, etc. With this, you could actually alter the way that your program feeds back after the first execution, because you could also inject write()'s, etc. (a lot more work would be needed)