[Python-Dev] strncpy

Greg Stein gstein@lyra.org
Thu, 13 Jul 2000 02:31:59 -0700


On Thu, Jul 13, 2000 at 02:53:07AM -0500, Paul Prescod wrote:
> Greg Stein wrote:
> > 
> > Actually, I looked into this a few months ago.
>...
> If we don't care about floating point, I think that there are about a
> dozen snprintf's we could steal (legally) around the Web. The author of
> the one I found says:

We don't care about anything except for %d, %s, possibly %c and %x.

> > In retrospect, it appears that a lot of effort was wasted by 
> > many people for not being aware of what others are doing. Sigh.

IMO, there is a complexity tradeoff. A short formatter for a few codes, or
pick up a complete implementation? And we *do* have some specific
requirements. We need to format into a PyStringObject rather than a
user-provided buffer/len like snprintf() does.

> Greg proposes:
> > %.###s  -- switch to %s
> 
> Isn't %.###s useful? If some yahoo gives us a 200 character variable
> name, is it really useful to quote it all back?

They did it, we can send it back. No biggy.

The *reason* the %.###s is in there is to prevent buffer overruns. It isn't
there for "nice output / truncation." Logically, it doesn't need to be
there.

> For NameErrors and UnboundLocalErrors in ceval, I'm just going to use
> PyString_Format. If that's not solid, we're in big trouble. Okay, it
> isn't so fast but we're talking about relatively rare exceptions -- not
> IndexError or AttributeError.

PyString_Format() requires Python objects for arguments. That is a
completely different beast from PyErr_Format() (or the PyErr_SafeFormat that
I described in that email).

If you're going to create a PyStringObject for the format and one for the
argument, then pass it to PyString_Format, then toast those temporaries...
then you're going about it wrong. :-)

A simple, *safe* string formatter for C types is needed within the core.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/