[Python-Dev] Re: [Python-checkins]python/dist/src/Objects unicodeobject.c, 2.197, 2.198 (original) (raw)

Tim Peters tim.one at comcast.net
Mon Sep 22 14:25:26 EDT 2003

[Tim]

At the moment, it appears there's no identified reason to care about signedness of a greater-than 16-bit type,

[M.-A. Lemburg]

Sure there is: first of all, having a single type that can be signed on some platforms and unsigned on others is a bad thing per se

We inherit that from C, though -- it's fine by C if wchar_t is signed or unsigned, just as it refused to define the signedness of char.

and second the 32-bit signed wchart value was what triggered this thread in the first place.

What triggered the thread originally was a segfault due to the code making a branch based on the content of uninitialized memory. The code clearly didn't think it was reading up random heap bits, so that was a bug regardless of wchar_t's signedness. That wchar_t happened to be a signed 32-bit type on Jeremy's box is what uncovered the read-uninitialized-memory bug.

If there's no other code vulnerable to bad behavior if wchar_t is a signed 32-bit type (nobody has identified another case), objections to it being signed anyway seem technically groundless. Martin did give a technical reason (efficiency) for wanting to continue to use wchar_t on Jeremy's system.

More information about the Python-Dev mailing list