[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/