Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!stc!btnix!winton From: winton@btnix.axion.bt.co.uk (Neil Winton) Newsgroups: comp.os.vms Subject: Re: printf bombs in VMS C if format too long Message-ID: <518@btnix.axion.bt.co.uk> Date: Mon, 6-Jul-87 11:29:11 EDT Article-I.D.: btnix.518 Posted: Mon Jul 6 11:29:11 1987 Date-Received: Sun, 12-Jul-87 09:21:34 EDT References: <1766@ttrdc.UUCP> Organization: British Telecom Research Labs, Martlesham Heath, IPSWICH, UK Lines: 37 in article <1766@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) says: > > When trying to port a C program which runs just fine on UNIX systems to VMS > I came across a problem with VERY long formats (over 512 characters). The > symptom is that the program dies with an Access Violation which prints out a > Stack Dump and a message about improper handler, image exit forced. (No > offending program line is indicated in the stack dump.) > [...] > Has anyone already SPR'd this? Is it fixed in a version of VMS C later than > 2.1? Is this a "documented" "feature"? UNIX systems don't choke on this > kind of format, which can be used to provide a template for a long, many-line > message which needs only one call to printf to instantiate. ``That ain't no bug, it's a feature!'' (Definition of `feature' --- a bug that has been documented) The limit of 512 characters on (fs)printf() output strings is documented on page 16-18 of the VAX C 2.0 reference manual. It certainly exists in releases up to 2.2. Interestingly, we have just received VAX C 2.3 and the (new, very good idea) separate Run-time Library reference manual makes no mention of this limit. However, owing to DEC's policy of only delivering the Run-time Libraries with updates to VMS we don't yet have the 2.3 RTL yet, because we don't have VMS 4.6, so I can't check it out! (Now someone really ought to SPR that piece of policy ... :-) BTW, release 2.3 is draft-ANSI conformant and there are some interesting new additions to the RTL, such as `atexit()' and the missing `memory(3C)' routines, but there are some major disappointments (no sharing of STMLF files) (and no real fork() :-). Neil E-Mail (UUCP) winton@axion.UUCP NWinton@axion.bt.co.uk ...!ukc!axion!winton Organisation British Telecom Research Laboratories (R11.4.1) Snail Mail BTRL, Rm 23 B68, Martlesham Heath, IPSWICH IP5 7RE, UK Telephone +44 473 646079 (or +44 473 643210) "You're never alone with a rubber duck..." --- Douglas Adams