home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16760 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  1.6 KB

  1. Path: sparky!uunet!ferkel.ucsb.edu!ucsbcsl!ucsbuxa!6500msd
  2. From: 6500msd@ucsbuxa.ucsb.edu (Michael D'Errico)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Funny problem with a pause routine
  5. Message-ID: <6770@ucsbcsl.ucsb.edu>
  6. Date: 19 Nov 92 01:49:12 GMT
  7. References: <9232123.22703@mulga.cs.mu.OZ.AU>
  8. Sender: root@ucsbcsl.ucsb.edu
  9. Lines: 41
  10.  
  11. In article <9232123.22703@mulga.cs.mu.OZ.AU> carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer) writes:
  12.  
  13. >ok, here's a routine I copied from a book, and can see no reason why
  14. >it won't work, but first, some background ..
  15.  
  16. >[background deleted]
  17.  
  18. >void pause()
  19. >{
  20. >    char ans;
  21. >    fflush(stdin);
  22. >    fprintf(stdout, "Press <Return> to continue\n");
  23. >    ans = getchar();
  24. >    fflush(stdin);
  25.  
  26. >    return;
  27. >}
  28.  
  29. >I've tried this with the getchar cast to void [ (void)getchar(); ],
  30. >and tried gets(), getc() etc, all to no avail.
  31.  
  32. There are two things I don't like about this code (this is not a flame):
  33.         1) pause() is a UNIX system function
  34.            defined in <unistd.h> so you should
  35.            refrain from using that name.
  36.  
  37.         2) getchar() returns an INT!!!  This is so
  38.            that EOF can be returned -- it doesn't
  39.            fit in a char.  This has repeatedly been
  40.            discussed in this newsgroup since there
  41.            is a tendancy to assume that a function
  42.            called getchar() returns a char.  It is
  43.            far worse when a book claims this.
  44.  
  45. I tried this code on my HP 9000 433s with cc and had no problems
  46. with it even with the 'char ans;' declaration, so I don't know what
  47. your problem could be...
  48.  
  49. Michael D'Errico
  50. 6500msd@ucsbuxa.ucsb.edu
  51.  
  52.