dave@utcsrgv.UUCP (Dave Sherman) (11/13/83)
That "int nextch" is interesting. That implies that on a 68000 machine,
the convention of getc reading into an int, so you can test for -1 while
still allowing a 0-255 range of chars, will break.
Am I misinterpreting things, or will this screw up a large percentage
of stdio programs?
Dave Sherman
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davechris@umcp-cs.UUCP (11/14/83)
No, it's not a stdio bug. The trouble is that uucp passes the
address of nextch to read. read expects a pointer to char; &nextch
is a pointer to int. Now, it just so happens that on PDP-11s and
Vaxen, the low byte of the int is where the "char" piece is. On
a 68000, the low byte of the int is somewhere else. The read
actually fills in the 3rd of 4 bytes.
Stdio does nothing so ugly; all it ever passes to read is pointers
to char. It then extracts the chars one at a time and converts
them to ints using the (almost portable) expression "*buf++ & 0377".
This works on all machines with eight bit chars. (Look out Univac!)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relayka@hou3c.UUCP (11/14/83)
It used to be that the value returned by the '=' operator in C was the right hand side. Unfortunately, the C Reference Manual claimed that the value was the *left* hand side. (I recall that the C Tutorial documented the '=' operator correctly.) Eventually this discrepancy was discovered, and was resolved in favor of making the value be the value of the left hand side. This meant that all the loops looking like char c ; while ((c = getchar()) != EOF) ... ; had to be changed, but until very recently the UNIX developers at BTL have been more concerned with doing things right than with maintaining compatability. Kenneth Almquist