[Python-Dev] 2.4 vs Windows vs bsddb

[Gregory P. Smith]

On Mon, Oct 09, 2006 at 08:11:59PM -0400, Tim Peters wrote:
> [Tim]
> > I just noticed that the bsddb portion of Python fails to compile on
> > the 2.4 Windows buildbots, but for some reason the buildbot machinery
> > doesn't notice the failure:
> 
> But it does now.  This is the revision that broke the Windows build:
> 
> """
> r52170 | andrew.kuchling | 2006-10-05 14:49:36 -0400 (Thu, 05 Oct
> 2006) | 12 lines
> 
> [Backport r50783 | neal.norwitz.  The bytes_left code is complicated,
>  but looks correct on a casual inspection and hasn't been modified
>  in the trunk.  Does anyone want to review further?]
> 
> Ensure we don't write beyond errText.  I think I got this right, but
> it definitely could use some review to ensure I'm not off by one
> and there's no possible overflow/wrap-around of bytes_left.
> Reported by Klocwork #1.
> 
> Fix a problem if there is a failure allocating self->db.
> Found with failmalloc.
> """
> 
> It introduces uses of assert() and strncat(), and the linker can't
> resolve them.  I suppose that's because the Windows link step for the
> _bsddb subproject explicitly excludes msvcrt (in the release build)
> and msvcrtd (in the debug build), but I don't know why that's done.
> 
> OTOH, we got a lot more errors (about duplicate code definitions) if
> the standard MS libraries aren't explicitly excluded, so that's no
> fix.

It seems bad form to C assert() within a python extension.  crashing
is bad.  Just code it to not copy the string in that case.  The
exception type should convey enough info alone and if someone actually
looks at the string description of the exception they're welcome to
notice that its missing info and file a bug (it won't happen; the
strings come from the BerkeleyDB or C library itself).

As for the strncat instead of strcat that is good practice.  The
buffer is way more than large enough for any of the error messages
defined in the berkeleydb common/db_err.c db_strerror() function but
the C library could supply its own unreasonably long one in some
unforseen circumstance.

-greg