chris@hwcs.UUCP (Chris Miller) (11/05/84)
In the course of installing the user-contributed program "bib" on
4.2bsd, I found a most puzzling bug. "Bib", like "refer", uses an
inverted index giving a file, character offset and length for each
instance of a keyword. All offsets and lengths were being created as 0
by "invert", the inversion program.
Investigation revealed that an intermediate file was being scanned for
keyword entries by
sscanf(line,"%s%s83/03/29D", key, file, &start, &length);
(I'm not sure whether the embedded date is exactly right!). From this,
it is immediately obvious :-) that the file was originally maintained
using SCCS, and that the authors had originally written
sscanf(line,"%s%s%D%D", key, file, &start, &length);
The %D% was then translated by SCCS to the current date!
I am not sure which is more irritating: that a piece of distributed
(albeit "unsupported") software goes out containing a trivial bug which
breaks it completely, or that a standard tool like SCCS has been
designed so as to be able to break a perfectly reasonable piece of
code. (Yes, I know that there are ways around the problem).
Addendum:
My investigation of "bib" was sparked off by discovering that "addbib"
is also completely (but trivially) broken in the 4.2bsd release, since
it fails to clear the EOF condition after reading an abstract, and
subsequently goes into an infinite read-prompt loop. Sometimes (very
rarely) words fail me.
--
Chris Miller
Department of Computer Science
Heriot-Watt University
...!ukc!{edcaad,west44}!hwcsguy@rlgvax.UUCP (Guy Harris) (11/10/84)
> In the course of installing the user-contributed program "bib" on > 4.2bsd, I found a most puzzling bug.... > > Investigation revealed that an intermediate file was being scanned for > keyword entries by > > sscanf(line,"%s%s83/03/29D", key, file, &start, &length); > > ...it is immediately obvious :-) that the file was originally maintained > using SCCS, and that the authors had originally written > > sscanf(line,"%s%s%D%D", key, file, &start, &length); > > The %D% was then translated by SCCS to the current date! > > ...or that a standard tool like SCCS has been designed so as to be able > to break a perfectly reasonable piece of code. SCCS was originally done under a version of UNIX (PWB/UNIX 1.0, if not an even earlier version) that may only have supported "%ld" for printing long ints, or which advertised "%ld" as the preferred method. V7 supported both, but mentioned "%D" first, which may have induced people to use it. System III got rid of "%D", supporting only "%ld", because they changed "%X" to mean "use capital A-F for the digits 10 through 15"). Moral: don't use "%D", use "%ld" instead - not only will it keep SCCS from breaking your code (unless another routine uses "%D" in strings), but it will make it more likely that your code will work under USDL UNIX. (While you're at it, don't assume "sprintf" returns a pointer to the buffer it filled in, either.) > Addendum: > > My investigation of "bib" was sparked off by discovering that "addbib" > is also completely (but trivially) broken in the 4.2bsd release, since > it fails to clear the EOF condition after reading an abstract... I've seen a later version of the 4.2BSD Standard I/O library, in which it seems they backed the "sticky EOF" change out. Sort of like Bell backing the "sorry, only one external declaration" change to the UNIX C implementation out of System V. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
rusty@sdcc3.UUCP (Rusty Wright) (11/24/84)
maybe this is why the use of %ld is encouraged over %D?
Ron Natalie <ron@BRL-TGR> (11/26/84)
Because, ATT adopted the standard of upper case letters meaning print the number in upper case. This really only has meaning for %X. -Ron