[Python-Dev] RE: Unicode character name hashing

[Tim Peters]

[/F]
> fwiw, "ucnhash" might be slightly obsolete (see my "unicodenames" patch
> for a smaller replacement).  as far as I can tell, my hash function should
> work on a 64-bit machine...

Will look at it once I find it <wink>.

> ...on the other hand, it currently assumes that an "int" is at
> least 32 bits.
>
> should I change this?

Absolutely!  "long" is the only way current C has to spell "at least 32".  A
natural opportunity to put some C9X-derived typedefs into pyport.h, like

typedef long Py_int_fast32_t;
typedef unsigned long Py_uint_fast32_t;

That may be a lie on some 64-bit machines, but it's a benign lie (i.e., will
still *work*), and people working on those machines can slop in the #ifdef's
they need to cut those back to int (or even short) when appropriate.

> do we still pretend to support 16-bit computers?

I don't, but we're interested in minimizing the amount of telepathy needed
to understand the code regardless.  Guido most often used "long" to mean "at
least 32" elsewhere in the codebase (this is why the Reference Manual
guarantees that a Python int is at least 32 bits, i.e. because C guarantees
"long" is) -- in accord with good C practice at the time, and, as it turned
out, with what ISO/ANSI standardized.  "int" doesn't mean anything to me
when I see it except "huh -- this code is probably going to break someday"
<0.5 wink>.  The C9X typedefs allow to remove all guessing about intent.