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!bellcore!ulysses!cbosgd!ucbvax!info-vax From: info-vax@ucbvax.UUCP Newsgroups: mod.computers.vax Subject: Re: VMS C help needed Message-ID: <8602101403.AA20845@rti-sel> Date: Mon, 10-Feb-86 09:03:20 EST Article-I.D.: rti-sel.8602101403.AA20845 Posted: Mon Feb 10 09:03:20 1986 Date-Received: Thu, 13-Feb-86 20:59:53 EST References: <8602070150.AA10267@ucsf-cgl.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Random Organization: Research Triangle Institute, RTP, NC Lines: 21 Approved: info-vax@sri-kl.arpa In article <8602070150.AA10267@ucsf-cgl.ARPA> conrad@UCSF-CGL.ARPA (Conrad Huang) writes: >I've been converting a program to run under VMS C C2.0-003. If I use >the old library from VMS C V1.xxx (crtlib.olb), everything works fine. >When I use the new library (vaxcrtl.olb, creation date 27-APR-1985), >sscanf() seems to fail at random intervals; that is, sscanf() claims >there are no matches (returns -1) even though the input string is >"1 molecules\n" and the format string is "%d molecules". Has anyone >else seen anything similar? > This sounds familiar. I had the same problem with C 2.0. The problem is fixed in C 2.1 or VMS 4.2 (which comes with the vaxcrtl.exe) If either is not a viable option, You can patch the vaxcrtl.exe. That is what I did to fix it. It seems that sscanf sets up a data area on the stack and then calls a common routine for sscanf, scanf and fscanf. The common routine promptly checks a bit in the stack data area that is never initialized by sscanf. All you need to do is determine the byte checked and have patch insert a clrb x(sp) at the appropriate location. Sorry I can't send you the patch, but I deleted it after vms 4.2 came out. You can find the location easily by following the code in the debugger. I believe the common routine accessed the data with a bitb 41(R?) instruction.