Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!beta!unm-la!unmvax!hi!hc!ames!ucbcad!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA
Newsgroups: comp.os.vms
Subject: Re: printf bombs in VMS C if format too long
Message-ID: <8707012344.AA10935@ucbvax.Berkeley.EDU>
Date: Wed, 1-Jul-87 19:44:52 EDT
Article-I.D.: ucbvax.8707012344.AA10935
Posted: Wed Jul  1 19:44:52 1987
Date-Received: Fri, 3-Jul-87 04:16:10 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Distribution: world
Organization: The ARPA Internet
Lines: 55


    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.)

	...

The VAX C implementation of printf uses a pre-allocated buffer to store the
results of doing the formatting.  The buffer has a fixed length, which is
still, last I heard, 512 bytes.

    Has anyone already SPR'd this?

Probably.

				    Is it fixed in a version of VMS C later
    than 2.1?

No.  I believe it is classed as a "permanent restriction".

	        Is this a "documented" "feature"?

Yes.  (Sorry, I don't have the manual here so I can't give you the reference.)

						   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.

Implementations of printf on Unix systems vary.  Some - most? - do single-
character output for the results of a printf; they can handle printf's of
arbitrary size, but can be slow, especially when used with unbuffered files.
(Note that VAX C files that point to real terminals are essentially
unbuffered.  This avoids a common problem that beginners run into on Unix
systems:  They write a prompt, or even a little message indicating where their
program has gotten to so far, and are puzzled when running the program results
in no apparent output.  The answer, of course, is that the output is sitting
in a buffer somewhere - an fflush() is required.  In the case of a prompt, I'm
told some recent Unix implementations will flush output to the terminal when
any input from it is done, easing the pain.  The VMS implementation leans
toward making stuff visible as soon as possible.  As a result, single-
character I/O to a terminal can be very expensive.  This is especially
noticeable on remote terminals, when you've SET HOST.)

I am told that there have existed Unix implementations that implemented printf
using a fixed buffer, too.  Your program would fail on those, too.

The reason for the particular failure mode you see is that the buffer that
printf allocates is on the stack.  When you over-run it, you clobber random
things on the stack, like the return address from printf().  Exactly what
happens after that is pretty unpredictable.

							-- Jerry
-------