johanw@ttds.UUCP (Johan Widen) (11/10/83)
We have recently installed uucp on an Altos 68000 and a Perkin Elmer. Naturally we found some bugs in uucp. A fix of these bugs will enhance portability but will probably not change the behaviour of already running uucp's. Bug 1: conn.c expect() near line 842 842c842 < int nextch = 0, kr; --- > char nextch = 0; int kr; Description: nextch appears in a statement "read(fn, &nextch, 1);" Its okay for nextch to be an int on a DEC machine but the read char will end up in the most significant part of the word on say a MC68000. Bug 2: gename.c getseq() near line 64 64c64,65 < fprintf(fp, "%s", sprintf(snum, "%04d", ++n)); --- > sprintf(snum, "%04d", ++n); > fprintf(fp, "%s", snum); Description: sprintf is not guaranteed to return a pointer. Check with your manual. Bug 3: pk0.c chksum() near line 626 626c626 < if ((unsigned)sum <= t) { --- > if ((unsigned short)sum <= t) { Description: (very subtle) sum is declared as short and t is declared as unsigned short. Have a look at the Perkin Elmer: sum is sign extended to a full int before it is converted to a unsigned. If sum is negative we will end up with a large 32-bit (positive) integer, which is compared to a 16-bit non-negative integer. Bug 4-100: This is really a misfeature in the Altos C-compiler. To speed things up on the MC68000 they have made int's 16-bit. Pointers are naturally 32-bit. Guess what happens when you dont declare malloc() as char *, or when you move a pointer to an int for a while. A program which runs on the Altos can claim to be portable...
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