Cool!

Who is filing it from our forum ?

To me, this violates the requirement to "not make use of files or any extrnal means of storing some data."

Sorry, where is other file used or what is the other means of storing the data here.

The file from which it is run therefore in the binary ( exe ) file the buf is written into and what is the other means of storing the data here ?

The executeable is a file and data ""0000000000" is being stored there.

Yeah, but it's not enough to put it on the man page. The kernel needs to operate that way. Your program should not have worked on Solaris.
In the bad old days, a process was a hodge podge of intermingled code and data. There was no distinction between code and data. A program could rewrite itself on the fly and this was thought to be cool. Then the concept of separating code and data arose. The idea was that "code" (instructions) should not be modified while data needed to be modified. A further refinement occurred when folks realized that some data was constant in nature and also should not be modified. Now the non-modifiable part of a process was renamed to "text". The cpu can guarantee that text is not modified. What's more, if two different users run the same program, both processes can use the same text segment. This is "shared text". Then came virtual memory where a very large program can be run in a small amount of physical memory by paging stuff in-to and out-of core as needed. In virtual memory systems, the text segment is read as it is needed.

This is why the Solaris behavior is so very wrong. If you and I run the same program, our processes share the text segment. If you modify your text segment, you modify mine as well. The separation between processes has been lost. Our entire text segment may not be in core. If you modify the program on disk, we may then page in the modifed data. Our shared text segment can now change, undermining the guarantee that the text segment is stable.

matrixmadhan, I meant that Sun themselves might actually notice that their OS now has unstable processes. If not, then someone with a support contract may raise the issue. A non-customer has no standing to demand repairs on an OS. It's hard enough to get stuff fixed when you are a customer (been there, done that). No way am I going to try to get something fixed as a non-customer.

If we are not allowed to store the output from the compiler into a file, then I will concede defeat. Not only is this challenge impossible, but it is now impossible to run any processes at all.

The original challenge clearly allows the program to be compiled. But it does not allow the program itself to use "files". It does not exclude the executeable file from the no use requirement.