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