Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!cybvax0!amit
From: amit@cybvax0.UUCP (Amit Green)
Newsgroups: comp.unix.wizards,comp.os.minix
Subject: obscure questions on sprintf(3S)
Message-ID: <1484@cybvax0.UUCP>
Date: Wed, 9-Sep-87 00:44:43 EDT
Article-I.D.: cybvax0.1484
Posted: Wed Sep  9 00:44:43 1987
Date-Received: Thu, 10-Sep-87 05:40:58 EDT
Reply-To: amit@cybvax0.UUCP (Amit Green)
Organization: Cybermation, Inc., Cambridge, MA
Lines: 71
Keywords: printf
Xref: mnetor comp.unix.wizards:4153 comp.os.minix:1591

Hello,

I am implementing a secure version of sprintf(3S), something that won't
randomly overrun buffers.

Until now I have been using a large buffer, calling sprintf(3S), and
checking that it didn't overwrite the last element of the buffer, in
which a '\0' had been placed, aborting with a "memory corrupted by
sprintf" error if it did.

Although workable, and probably reasonably proof against errors, I
prefer to implement something more secure.

Since we don't have source; its a bit hard to find how sprintf(3S)
works in some of the more obscure areas.

I would like help from anyone who can legally divulge it* (See
footnote).

I especially want to know what the output for %e, %f, and %g formats
are with various field width's and precision.

Looking at "nm -pg /lib/libc.a" seems to indicate that _doprnt(3S) does
not call any of the ecvt(3) routines, as I had espected, making
emulating these routines rather difficult.

Unless I can find some way to exactly match the output of these formats
with all different field options, I am going to reconstruct a "%"
format (with field widths under 128 characters to avoid the overruning
internal buffers) and calling sprintf(3S) on this small buffer, then
copying it with bound checking to the user buffer; I prefer a
different way if possible, thus this note.

I have been testing the sprintf(3S) implementation on our BSD 4.2
system (actually Ultrix 1.?); and have come to the following
conclusions on the other simpliar formats:

1.  "%*s", -10, "hi"		Will left adjust "hi".
    "%-*s", -10, "hi"		Will right adjust "hi" (the two negatives
				cancel)

2.  "%-05d", 2			Will ignore the zero-padding.

3.  "%05d", -2			Will zero-pad after the "-" sign.

4.  "%05#x", 2			Will zero-pad after the "0x" prefix.

6.  "%5%"			Will actually put the "%" in the specified
				width, left/right justfied, etc.

7.  "%05s", "hi"		Will zero-pad the string.  I expected it
				not to, but on second thought, this does
				have some uses.

The rest of the formats seems to be as expected, any illogical fields,
such as "%-0.#ls", are ignored.

Please respond by mail; I doubt many people on the net are interested
in this.   Thank you.


					{mit-eddie,harvard}!cybvax0!amit
					Amit Green

Footnote
=========
	*That is, I believe looking at AT&T code and explaining it's
algorithm it not allowed due to trade-secret status.  However, if anyone
with a minix system can send me source code for just the relevant parts
legally, please do so [Does minix even do floating point?  I somehow
get the feeling it might not].  Thank you.