libaps-general Mailing List for Application Print Services Library (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

From: "Jeff Brown" <jef...@co...>
Subject: The dangers of using sprintf().
Date: Tuesday, February 08, 2000 6:08 pm

Hello everyone,

I'm sure you're all aware of the problems surrounding the use of such
functions as sprintf(), strcpy(), strcat() etc...  For the longest time I
was wondering why there did not seem to be a variant of sprintf() which
dynamically allocated the buffer it needed or which could accept a maximum
size.

Apparently, I was wrong... I would like to direct your attention to
asprintf() and snprintf() which perform the above tasks splendidly.  If
portability issues arise, it is fairly trivial to provide safe / safer
frontends to sprintf() conforming to the above definition.

I would suggest doing a grep on your source files and look at ways of
avoiding the use of sprintf() with fixed-length buffers.  If it's possible
to compute the total length beforehand and the string is local to a
function, use alloca() to create the buffer.  alloca() is fast, almost
guaranteed to succeed, and needn't be free'd() as the buffer gets popped off
the stack when the stack unwinds because of the function returning or some
exception.

From: "Brian Pirie" <br...@co...>
Subject: Re: The dangers of using sprintf().
Date: Wednesday, February 09, 2000 10:33 am

asprintf() and snprintf() are wonderful functions! In my opinion, it is a
real
shortcoming of the ANSI C standard that these (and other functions, such as
strdup()) aren't included.

You're right that if we want to do something like this, we need to be very
careful of portability. In the front-end functions you're suggesting, if
we're
building on a plain-ANSI C compiler that lacks asprintf() or snprintf(), how
would we determine how long the string is going to be without essentially
implementing a complete printf-format parser, that looks at each % field to
determine how long the buffer needs to be?

There are places in the code where we're using sprintf() or atoi(), where we
are
careful that the destination buffers are appropriately sized for the largest
data that we can have. Because, as you point out, this is really dangerous,
at
the very least we should have ASSERTs() to test for any assumptions we're
making
about maximum sizes.

Do you have any other ideas for things that we can do to reduce the danger
in
these sorts of situations?

Brian

From: "Jeff Brown" <jef...@co...>
Subject: Re: The dangers of using sprintf().
Date: Wednesday, February 09, 2000 12:57 pm

> You're right that if we want to do something like this, we need to be very
> careful of portability. In the front-end functions you're suggesting, if
we're
> building on a plain-ANSI C compiler that lacks asprintf() or snprintf(),
how
> would we determine how long the string is going to be without essentially
> implementing a complete printf-format parser, that looks at each % field
to
> determine how long the buffer needs to be?

There is little other choice.  Thankfully, printf is not something very
complex.  However we're overlooking something here.  Portable
implementations of these functions must exist already in OpenSource.  We
would then need only place those modules in the contrib/ folder or similar.

If it comes to writing a new printf()-like formatter, all I can say is that
it's actually much easier than it looks.  *smile*

> There are places in the code where we're using sprintf() or atoi(), where
we are
> careful that the destination buffers are appropriately sized for the
largest
> data that we can have. Because, as you point out, this is really
dangerous, at
> the very least we should have ASSERTs() to test for any assumptions we're
making
> about maximum sizes.

As you pointed out, there is no way of building ASSERTs for such conditions
short of writing a printf-style parser.

> Do you have any other ideas for things that we can do to reduce the danger
in
> these sorts of situations?

Build strings atomically using strncpy() and strncat() where appropriate.
Or, as I suggested, try to precompute the length of the string beforehand
and make a call to alloca() to allocate your buffer for you.  If you're
dead-set on using static buffers, insert field width qualifiers into the
sprintf() format string.  eg. "%20s %5d".

Jeff Brown. (x5625)

From: "Brian Pirie" <br...@co...>
Subject: Re: The dangers of using sprintf().
Date: Wednesday, February 09, 2000 3:21 pm

> complex.  However we're overlooking something here.  Portable
> implementations of these functions must exist already in OpenSource.  We
> would then need only place those modules in the contrib/ folder or
similar.

Unfortunately, unless they're released under the LGPL license, we can't use
them. Even GPLed code would be off-limits.

> > data that we can have. Because, as you point out, this is really
> dangerous, at
> > the very least we should have ASSERTs() to test for any assumptions
we're
> making
> > about maximum sizes.
>
> As you pointed out, there is no way of building ASSERTs for such
conditions
> short of writing a printf-style parser.

What I had in mind is if you had a piece of code that did something like:

char dest[5];
sprintf(dest, "%d", value);

This code is assuming that value will never be more than 4 digits. So, you
could
do an:

ASSERT(value < 10000 && value > -1000);

To make it immediately obvious if that assumption was ever violated.

Brian

From: "Jeff Brown" <jef...@co...>
Subject: Re: The dangers of using sprintf().
Date: Wednesday, February 09, 2000 4:47 pm

> What I had in mind is if you had a piece of code that did something like:
>
> char dest[5];
> sprintf(dest, "%d", value);

> This code is assuming that value will never be more than 4 digits. So, you
could
> do an:
>
> ASSERT(value < 10000 && value > -1000);

ICK!  There must be a better way, but I see your point.  There's no reason a
programming language couldn't hide these internals from view, geez...

If the above construction were to be used in many places, I would consider
writing a macro or inline'd function for handling the circumstance.