Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: ipcrm bug
Keywords: SunOS
Message-ID: <1125@auspex.UUCP>
Date: 15 Mar 89 21:27:58 GMT
References: <8902232004.AA10516@terminus.Morgan.COM>
Sender: usenet@rice.edu
Organization: Auspex Systems, Santa Clara
Lines: 27
Approved: Sun-Spots@rice.edu
Original-Date: 6 Mar 89 18:59:18 GMT
X-Sun-Spots-Digest: Volume 7, Issue 201, message 2 of 15

>Especially since on System V systems ipcrm takes keys specified in hex.

I found this difficult to believe, especially given that the SunOS 3.x
"ipcrm" is derived from the S5R2 "ipcrm" and the SunOS 4.0 "ipcrm" is
derived from the S5R3 "ipcrm".  In fact, vanilla S5R3's "ipcrm" uses
"atoi" to convert the key from ASCII to a number, which means it does
*not* take keys in hex.  Perhaps the S5 system on which you tried it has a
modified version of "ipcrm"?

I agree that it should accept keys in hex, though; however, you should
send this complaint not only to Sun, but to AT&T, so that it gets fixed in
S5R4 and thus gets fixed not only in Sun systems, but other systems.

The easiest fix is probably to change it to use "strtol", which means
that:

	1) it can do a better job of checking for invalid strings;

	2) it can be made to accept C-syntax numbers, so that preceding
	   the key with "0x" causes it to be interpreted as hex (and
	   preceding it with "0" causes it to be interpreted as octal)

Making it accept only hex keys may cause compatibility problems (or, at
least, AT&T may consider there to be a risk of incompatibility).

Perhaps it has already been fixed in S5R3.2; I don't have S5R3.2 source
handy.