Historical C/stdio question?
Clem Taylor
of the parameters to sprintf? Or when they got around to generating the
ANSI spec, why they didn't they fix this problem? At that point wasn't it
well known that this type of function (and it's dreaded cousin gets()) are
a monster security black hole? If they didn't want to muck with the
function proto, at least they could have done is add a %z or somesuch so
you can specify the size... *printf lets you get at the current number of
chars written so far, so adding this shouldn't have required much effort,
a little speed hit, but thats another issue...
I know you can do stuff like:
char s [ 150 ];
sprintf ( s, "%.75s %.75s", s1, s2 );
But if you decide to increase or even worse decrease the size, then it is
a pain in the ass to change.... And using something like:
sprintf ( s, "%.*s %.*s", compute size, s1, compute size, s2 );
is just as bad, because if you want to come close, you need to compute the
string lengths (wasteful)... Even worse, it adds way to much room to make a
mistake (off by one gets me everytime)...
Worse case, it would be nice if you could do something ugly (not that this
is a good idea) like add %z which would specify the size of the output
buffer. One thing that is good about doing it this way is it won't break
any existing code. Heres an example:
char s [ 42 ];
sprintf ( s, "%42z .... ", ... );
/* or... */
sprintf ( s, "%*z .... ", sizeof ( s ) / sizeof ( char ), ... );
but what is really needed (at this point) is a snprintf:
snprintf ( char *s, int size, char *format, ... );
Btw, I just spent many hours going though some code that needs to be
bulletproof++, trying to figure out what the worst case string sizes are for
various sprintfs... For the most part I could care less if not all of the
format could be expanded into my buffer, I just don't want sprintf to
squish things along the way...
Thanks for listening to me bitch...
Clem Taylor
Norman Diamond
>When stdio was being developed, why didn't they put a buffer size as one
>of the parameters to sprintf?
C was originally intended to be a substitute for assembly language, so that
system programmers could code low-level necessities without needing to learn
the syntax and some grungy behavior of yet another assembly language. Just
as in assembly language, safety was to be provided by the programmer's skill
and alertness and perfection, without help from the language. Anyone who
wanted help from a language still had to use a higher-level language.
>Or when they got around to generating the
>ANSI spec, why they didn't they fix this problem?
You mean, when people started having this heretical idea of bastardizing C
with plagiarisms from more type-safe languages? Well, they couldn't do it
to sprintf() and preserve the behavior of existing programs ... except that
your idea here is reasonable:
>at least they could have done is add a %z or somesuch so
>you can specify the size...
The real question is why they didn't add snprintf() to the standard.
For that, you'll have to ask the committee. Now, anyone know if snprintf()
might get into the next version of the standard?
--
<< If this were the company's opinion, I would not be allowed to post it. >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
Ronald F. Guilmette
Clem Taylor <cta...@stimpy.eecis.udel.edu> wrote:
>When stdio was being developed, why didn't they put a buffer size as one
>ANSI spec, why they didn't they fix this problem? At that point wasn't it
>well known that this type of function (and it's dreaded cousin gets()) are
>a monster security black hole?
I believe we may have another candidate for a possible future comp.std.c
FAQ list.
(By the way, the answer is the standard one... Existing Practice.)
--
-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: r...@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: r...@rahul.net ----------------- Suites and Bullet-Proof Shoes -
Dan Pop
>In article <3scsnk$o...@louie.udel.edu>,
>Clem Taylor <cta...@stimpy.eecis.udel.edu> wrote:
>>When stdio was being developed, why didn't they put a buffer size as one
>>of the parameters to sprintf? Or when they got around to generating the
>>ANSI spec, why they didn't they fix this problem? At that point wasn't it
>>well known that this type of function (and it's dreaded cousin gets()) are
>>a monster security black hole?
>
>(By the way, the answer is the standard one... Existing Practice.)
When did snprintf become existing practice?
Dan
--
Dan Pop
CERN, CN Division
Email: Dan...@mail.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Michael Meissner
| In <3slbm6$4...@hustle.rahul.net> "Ronald F. Guilmette" <r...@rahul.net> writes:
|
| >In article <3scsnk$o...@louie.udel.edu>,
| >Clem Taylor <cta...@stimpy.eecis.udel.edu> wrote:
|
| >>When stdio was being developed, why didn't they put a buffer size as one
| >>of the parameters to sprintf? Or when they got around to generating the
| >>ANSI spec, why they didn't they fix this problem? At that point wasn't it
| >>well known that this type of function (and it's dreaded cousin gets()) are
| >>a monster security black hole?
| >
| >(By the way, the answer is the standard one... Existing Practice.)
|
| When did snprintf become existing practice?
When Chris Torek rewrote the BSD stdio library a few years ago, he included
snprintf.
--
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meis...@cygnus.com, 617-629-3016 (office), 617-629-3010 (fax)
Chris Torek
>>When did snprintf become existing practice?
In article <MEISSNER.95...@tiktok.cygnus.com> Michael Meissner
<meis...@cygnus.com> answers:
>When Chris Torek rewrote the BSD stdio library a few years ago, he included
>snprintf.
I guess that makes it `existing practise' in some places anyway. :-)
(BSD/OS, FreeBSD, and NetBSD all have it now.)
Incidentally, the name and its semantics were the work of a group
(me, Keith Bostic, maybe a suggestion or two from someone else at
CSRG). The exact semantics are a little bit complicated:
The {,f,s}printf() functions return the number of characters put,
or EOF for error. To make snprintf more useful, it returns the
number of characters it *would have* put had the buffer size been
infinite. This means you can snprintf() into a small buffer, then
discover that the result was truncated, and how much space you need
to store it without truncation.
Annoyingly, you need snprintf()+1 bytes to store its result, because
of the terminating '\0'. For consistency with sprintf(), snprintf()
does not count this byte.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
Berkeley, CA Domain: to...@bsdi.com +1 510 549 1145