Hi,

there are some uses of sprintf in the Python C code.
Unfortunately sprintf is known to cause buffer
overruns. To prevent this I have written a patch that
replaces sprintf with snprintf. To be on the safe side
(and since I don't know much of the C code internals) I
only changed static buffers, where the sizeof()
operator is known to work.

The patch is against SVN 42293, and tested on a i386
Debian Linux system.

Logged In: YES 
user_id=21627

The patch has several problems:

1. It is unnecessary. The print calls actually *cannot*
cause buffer overruns, because in all cases, the buffers are
large enough.

2. The insertion of a trailing null-byte is unnecessary:
snprintf will already add that byte, even if it runs out of
space.

The first argument could be discarded, since using snprintf
can be considered as improving maintainability; point 2
actually decreases maintainability.

Logged In: YES 
user_id=9205

The snprintf had implementations which did not
null-terminate the buffer if it was too small. I detected
that Python itself has a wrapper function defined for that
reason: PyOS_snprintf.

I will attach a patch in the next days that makes use of
PyOS_snprintf, which should remove the trailing null-byte lines.

I noted that none of the calls of both sprintf and
PyOS_snprintf actually check the return code. But I found
out that Guido does not care, as said in this message:
http://permalink.gmane.org/gmane.comp.python.devel/33591

Logged In: YES 
user_id=9205

I added an updated patch that uses PyOS_snprintf, and only
in places where the Python headers are included.

Does anyone want to adopt this one? :)

I'm torn by this one.  Half of me says it's a good thing trying to be fail safe.  The other half says it's work for something that hasn't yet happened.  Any other views?

Most usages of sprintf here cannot cause buffer overruns: the output is bounded in size (%d, %8.8x, %.200s), and the buffer is large enough.

Moreover, some of them were already replaced by functions of the _FromFormat() family, which can handle unicode for example.

IMO the change is not worth it.

I'll close unless someone puts in a strong bid to keep this open.

Closing as noone has responded.