Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!pt.cs.cmu.edu!sei!prp
From: prp@sei.cmu.edu (Patrick Place)
Newsgroups: comp.bugs.4bsd
Subject: Re: cpio - segmentation violation
Keywords: cpio, negative UID
Message-ID: <3517@fy.sei.cmu.edu>
Date: 18 Jun 89 22:02:29 GMT
References: <1120@servax0.essex.ac.uk> <10406@smoke.BRL.MIL>
Organization: Carnegie-Mellon University (Software Engineering Institute), Pgh, PA
Lines: 25

In article <10406@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <1120@servax0.essex.ac.uk> peter@essex.ac.uk	 (Allott P) writes:
> >The problem is that some users have files on their areas with a uid of -2.
> 
> That NFS-induced modification to the concept of UID has caused numerous
> problems.  AT&T UIDs are unsigned (i.e. nonnegative) integers, and AT&T
> UNIX software relies on this.  (So did some BSD software.)  The whole
> issue of NFS ID mapping has been a real mess.


It is not so much a matter of having negative uids (which I admit is
unusual) as that on Suns for example,
	printf("%.6ho", -2)
will print a 10 character wide representation of -2, rather than
the requested 6 character representation.  I had exactly this problem
and fixed it by casting the offending value to a halfword, having
masked off all but the last 16 bits.  It seemed to work and allowed
me once again to read (and write) cpio archives.  I will grant that
the fix is not pretty, but I could not come up with any other way to
make printf print out a 6 character wide value.  To be fair, if I
recall my reading of the Sun manual page for printf, it doesn't
guarantee that it will limit the output to 6 characters, merely that
it will use 6 characters (ie pad if necessary).

Pat Place