Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!linus!decvax!genrad!wjh12!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: SCCS oddity
Message-ID: <228@rlgvax.UUCP>
Date: Sat, 10-Nov-84 11:20:16 EST
Article-I.D.: rlgvax.228
Posted: Sat Nov 10 11:20:16 1984
Date-Received: Sun, 11-Nov-84 20:08:11 EST
References: <258@hwcs.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 42

> 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