On architectures missing a native snprintf (checked on
win32 + Borland), PyOS_snprintf may cause a segfault
when passed a string argument (%s) larger than 512 bytes. 

Btw, allocating an extra 512 bytes and hoping for the
best while calling native vsprintf is also a security
risk (due to buffer overruns.)

Logged In: YES 
user_id=31435

Does it really cause a segfault?  This code is trying to cause 
Py_FatalError instead in that case:

else if ((size_t)len >= size + 512)
	Py_FatalError("Buffer overflow in 
PyOS_snprintf/PyOS_vsnprintf");

If that part isn't working, that is indeed a bug.

WRT security, PyOS_snprintf is an internal API function -- 
programs written in Python can't invoke it directly.  If a 
(necessarily) internal use of the function triggers this case, 
that's an error in the coding of the internals, but the *intent* 
is that Py_FatalError() get invoked then anyway, which 
immediately kills the Python process (via C abort()).

Logged In: YES 
user_id=10245

Yes, it causes a segfault when a module using PyOS_snprintf
passes it a string that is bigger than the buffer length +
512. This happens because first vsprintf is called with a
too small buffer and the stack is corrupted and then (too
late!)  there is the check and the fatal error.
Py_FatalError is called (maybe) but the return address is
gone from the stack and all you get is a segfault at the end
of the function.

I know PyOS_snprintf is internal but it can be used by
extension modules and (anyway) growing a buffer 512 bytes
statically is almost the same as using sprintf (without the
'n') directly.

Logged In: YES 
user_id=430343

Win32 actually *does* have snprintf, but like most functions added to the 
C standard later in life, it's implemented as _snprintf().  Really, it seems 
that the autoconf rule needs to be smarter than just checking for 
snprintf, but rather needs to redefine snprintf as _snprintf on platforms 
that have _snprintf.

Of course, the implementation of PyOS_snprintf still needs fixing.

Logged In: YES 
user_id=31435

Nick, Python already uses _snprintf and _vsnprintf under 
MSVC on Windows.  The OP said he tried using Borland on 
Windows, which presumably lacks them (Borland has its own 
runtime libraries, and do note that these things are not part 
of the Win32 API, they're part of the compiler-specific C 
runtime library).

Since snprintf and vsnprintf are required by both POSIX and 
the C99 standard, and are supplied (albeit with a goofy 
spelling, and non-standard endcase behavior) by MSVC, the 
number of platforms they're not available on is both small and 
shrinking.  I doubt any current Python developer uses such a 
platform, so if the OP doesn't care enough to volunteer a 
patch either, we should acknowledge reality and close this as 
WontFix.  (The OP could still ask Borland to modernize their C 
offering, of course -- if Borland is falling behind the times, it's 
not really Python's problem to write a modern C library for 
them.)

Logged In: YES 
user_id=1188172

Another year passed (almost), so this can be closed?

Logged In: YES 
user_id=31435

Indeed, nine months is long enough to make a baby, so
closing this as 3rdParty + WontFix.