home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / alt / hackers / 1363 < prev    next >
Encoding:
Text File  |  1992-09-03  |  1.8 KB  |  52 lines

  1. Path: sparky!uunet!utcsri!devnull
  2. Newsgroups: alt.hackers
  3. From: flaps@dgp.toronto.edu (Alan J Rosenthal)
  4. Subject: Re: Self Printing Program, revisited
  5. Message-ID: <1992Sep4.083327.15563@jarvis.csri.toronto.edu>
  6. References: <9lm-wK-@engin.umich.edu>
  7. Date: 4 Sep 92 12:33:28 GMT
  8. Approved: hyoop
  9. Lines: 41
  10.  
  11. {Note: When you get bored reading this article, skip to the end.}
  12.  
  13. positron@engin.umich.edu (Jonathan Scott Haas) writes:
  14. >Awhile back, there was talk about how to write a program whose
  15. >output would be the program itself. Here's my program, written
  16. >in C, but I think perhaps it "cheats" a bit.
  17. [reads its own source code from a file]
  18.  
  19. Well, is "cat" a self printing program because you can do
  20.     cat /usr/src/bin/cat.c
  21. ?  "Cat" is not an extremely exciting or novel program.  Your program is less
  22. exciting than cat.
  23.  
  24. Something similar but a little cooler is something in a microcomputer basic
  25. environment which uses peeks to list whatever program is in memory, just like
  26. the "list" command does, and thus lists itself.
  27.  
  28. However, none of these programs have the essential ingredient of a self-
  29. printing program, which is that the program contains itself in a certain
  30. sense.  In these programs, they have to go to some external area and look up
  31. the source.  For example, in your program, if you compile it and then delete
  32. the source it will stop functioning.  A proper self-printing program won't have
  33. this failing.
  34.  
  35. Here's a program which prints itself, except that it's somewhat buggy and
  36. sometimes dumps core instead.
  37.  
  38.  
  39. #include <signal.h>
  40.  
  41. int main()
  42. {
  43.     kill(getpid(), SIGBUS);
  44. }
  45.  
  46.  
  47. --
  48.  
  49. Why don't we discuss cool variant problems?  Did anyone like my pair of
  50. programs in different programming languages each of which output the other?
  51. What are some other good variant problems?  Post or e-mail.
  52.