Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!rayssd.UUCP!m1b.UUCP
From: m1b.UUCP@rayssd.UUCP (M. Joseph Barone)
Newsgroups: mod.computers.vax
Subject: Re: Potential C problem
Message-ID: <8607011825.AA28178@rayssd.UUCP>
Date: Tue, 1-Jul-86 14:25:11 EDT
Article-I.D.: rayssd.8607011825.AA28178
Posted: Tue Jul  1 14:25:11 1986
Date-Received: Thu, 3-Jul-86 00:37:50 EDT
References: <8606261652.AA25082@tektools.TEK>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The MITRE Corp., Bedford, MA
Lines: 31
Approved: info-vax@sri-kl.arpa


In article <8606261652.AA25082@tektools.TEK>, bobp@tektools.tek.CSNET
(Robert Perry) writes:
> 	Perhaps I missed something in the documentation, but can anyone
> tell me why the VMS C compiler doesn't allow a value of 0 in %x1 as in the
> following example ?
> [example follows using sscanf]

This is a real problem and has been SPRed (SPR NO. 11-CS01837).
The response DEC sent us follows:

	A change is made in VAX C RTL fscanf function (V2.1) to support
	"0x" input string and therefore incidentally ignores leading
	zeros if fscanf function is reading with a "%x" input format
	specifier.

	This problem will be fixed in a future release of VAX C RTL that
	will be shipped with a future version of VAX/VMS after VAX/VMS
	V4.2.  The change made for supporting "0x" input string will also
	be documented in the next edition of "Programming in VAX C".

	The workaround is to enter either a leading "0x" or a leading "0"
	to get the value 0 matched as you have indicated in your SPR.

We're still at V4.2 and when I looked through the V4.3 kit, I didn't find
any patches to VAXCRTL.OLB.  I don't know if this has truly been corrected
in V4.4.

Joe Barone
{allegra, cci632, gatech, ihnp4, linus, mirror, raybed2}!rayssd!m1b
Raytheon Co, Submarine Signal Div., 1847 West Main Rd, Portsmouth, RI 02871