Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830713); site hwcs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!ukc!edcaad!hwcs!chris
From: chris@hwcs.UUCP (Chris Miller)
Newsgroups: net.unix-wizards
Subject: SCCS oddity
Message-ID: <258@hwcs.UUCP>
Date: Mon, 5-Nov-84 12:11:40 EST
Article-I.D.: hwcs.258
Posted: Mon Nov  5 12:11:40 1984
Date-Received: Sat, 10-Nov-84 05:50:16 EST
Organization: Computer Sci., Heriot-Watt U., Scotland
Lines: 37

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}!hwcs