Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!claris!hearn From: hearn@claris.com (Bob Hearn) Newsgroups: comp.std.c Subject: Re: Portable Self-Replicating C Contest Message-ID: <9194@claris.com> Date: 27 Mar 89 20:15:12 GMT References: <1417@sw1e.UUCP> Organization: Claris Corporation, Mountain View CA Lines: 42 From article <1417@sw1e.UUCP>, by uucibg@sw1e.UUCP (3929]): > In article <12144@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >>Well, it happens that I was going to post this anyway... >> >>*** Portable Self-Replicating C Contest *** >> >>Rules: >>0. The output of the program must be its own source code. > > [ More of the rules of the contest ] > >>Followups to comp.std.c only. >> >>Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint >>(Why 72? The last eight columns are reserved for possible addition of a card >>sequence number at some future date.) > > This is a good opportunity for me to ask a question that's been bugging me for > quite a while: > > It seems that it would be impossible to create a program which generates it's > source as output because you have a self-referential system and will end up > with an infinite recursion. I guess this presumes that you can't go out to > the operating system to do things, since then it's not a strictly self-refer- > ential system. I note that this contest doesn't prevent you from going to the > operating system, it simply prevents you from opening the source file and > printing it out (that rule was in part of the text I deleted...sorry). But: > > Isn't it impossible for a C program to replicate itself if it doesn't access > the operating system (other than printing to stdout)? The question of whether > it can be done while *using* the OS should come out of this contest so I'll > wait patiently... > > By the way, please forgive me if this all seems trivially true/false...but > please enlighten me. > > > Brian R. Gilstrap Southwestern Bell Telephone > One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg > St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg > (314) 235-3929 > #include