Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC830713); site ttds.UUCP Path: utzoo!linus!philabs!mcvax!enea!ttds!johanw From: johanw@ttds.UUCP (Johan Widen) Newsgroups: net.bugs.uucp Subject: bug-fixes in uucp Message-ID: <134@ttds.UUCP> Date: Thu, 10-Nov-83 06:33:10 EST Article-I.D.: ttds.134 Posted: Thu Nov 10 06:33:10 1983 Date-Received: Sat, 12-Nov-83 06:10:51 EST Organization: Royal Inst. of Techn., Stockholm Lines: 48 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...