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

[Tim Peters]

[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 wchar_t 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.