A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/005625.html below:

[Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode

[Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decodeBill Tutt rassilon@list.org
Thu, 6 Jul 2000 13:53:47 -0700 (PDT)
On Thu, 6 Jul 2000, Tim Peters wrote:

> [moved from patches to python-dev]
> 
> [Bill Tutt]
> > Code currently in unicodeobject.c needs to do 32-bit arithmetic in
> > order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate
> > characters) require 32 bits to represent the true unicode code point of a
> > surrogate pair.
> 
> But is the requirement really for *exactly* 32 bits, or for *at least* 32
> bits?  The problem isn't with feebler machines, it's with higher-end ones:
> on some Python platforms, even sizeof(short) == 8.  As is, your patch will
> prevent Python from compiling on those.

Its definately for at least 32 bits. 
Having a 32 bit specific type lets me not worry about all the issues
relating to:
What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to 
compensate for that somehow.

Now, the code that I changed to use the typedef might not care about this,
but other code using the typedef might. Just color me a paranoid SOB. :)
I'd rather always have a 32 bit type for something I know will always
require just 32 bits.

Bill




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4