getc() != EOF; -1 byte in fi - (nf)

jim at ism780.UUCP jim at ism780.UUCP
Thu Jun 21 14:11:42 AEST 1984


#R:mcvax:-583600:ism780:14400012:000:1710
ism780!jim    Jun 12 22:10:00 1984

> [This discussion is getting silly.  Trying to stamp out one more
>  misunderstanding...]
> 
> Someone suggests that a -1 byte in the file can be promoted to EOF.
> 
> No it can't, for the simple reason that getc() is defined as returning
> an *int* in the range 0..255.  My v7 manual doesn't state this, but just
> have a short look at the definition of getc() in /usr/include/stdio.h!
> 
> Surely this was intended; the designers of the package were very well
> aware of what they were doing: the do warn that the value EOF (-1) returned
> by getw() [did you know that it existed?! ever used it?] can be a perfectly
> valid integer.
> 
> Of course, when assigned to a signed char variable, the values in the range
> 128..255 become negative; but only then.

I guess people so blinded by their desire to be more right than the other guy
that they insist on misreading and misinterpreting everything.
The last sentence indicates that you have all the info to realize that
the code under discussion {char c; while ((c = getchar()) != EOF) ...}
promotes -1's in the input to EOF on sign-extending machines,
yet you insist on contradicting that.  Sigh sigh sigh.

-- Jim Balter, INTERACTIVE Systems (ima!jim)


P.S.  For a really good joke, check out the treatment of putw.
      According to some version of the manual,

DIAGNOSTICS
     These functions return the	constant EOF upon error.  Since	this is	a good
     integer, ferror(3s) should be used to detect putw errors.

However, not only does putw not return its argument, so you shouldn't need
ferror to detect an error, but, contrary to the documentation, it does not
return EOF upon error; rather it returns the value of ferror() (0 or 1)
in any case.



More information about the Comp.unix.wizards mailing list