levy@ttrdc.UUCP (Daniel R. Levy) (06/18/87)
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 following snippet of code will exhibit the problem (VMS C 2.1):
main()
{
char hugefmt[520];
int i;
for (i=0; i<516; i++)
hugefmt[i] = 'X';
hugefmt[i++] = '%';
hugefmt[i++] = 'd';
hugefmt[i++] = '\n';
hugefmt[i] = '\0';
printf("HERE GOES...\n");
printf(hugefmt,1); /* *BOOM* 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.
--
|------------dan levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
| an engihacker @ | vax135}!ttrdc!ttrda!levy
| at&t data systems division | Disclaimer: try datclaimer.
|--------skokie, illinois--------|LEICHTER-JERRY@YALE.ARPA (07/02/87)
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
-------titley@btnix.axion.bt.co.uk (Nigel Titley) (07/06/87)
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.) I quote section 16.5.1 in the programming in Vax C manual "The string output by these functions can have a maximum length of 512 characters" I don't know if DEC have any plans to modify this, I doubt it somehow. -- Email: NTitley@axion.bt.co.uk Snail: British Telecom Research labs, Martlesham Heath, Ipswich, Suffolk, UK
winton@btnix.axion.bt.co.uk (Neil Winton) (07/06/87)
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