[Python-Dev] Deprecation warning on integer shifts and such

[Tim Peters]

[Guido]
> ...
> Actually, C is fairly careful: AFAIK on a 32-bit machine the type of
> 0xffffffff is unsigned long,

Close:  it's unsigned int.

> so it's not strictly -1,

Not close:  it's nothing at all like -1!  Try this:

#include <stdio.h>
void main() {printf("%d\n", 5 / 0xffffffff);}

If it "acted like" -1 this would print -5 instead of 0 (and if it doesn't
print 0, your compiler is broken).  Maybe more obvious is to do

    printf("%g\n", (double)0xffffffff);

That should pring something close to <wink>

    4.29497e+09

not

   -1

> and you'll have to use a cast somewhere to be able to compare it
> to an int.

If you want it treated like -1, definitely, because it's not -1.  If you
want it treated like 4294967295, then in the absence of an explict cast the
int you're comparing it to will get silently promoted to unsigned int too
(or with a warning msg, if your compiler is helpful).

>> uint8_t, uint16_t, uint32_t and uint64_t.

> Hm.  This is a big deviation from tradition.  Those types aren't
> currently used or defined.

Nor are they required to exist, not even in C99, where all the new "exact
size" typedefs are optional -- some boxes simply don't have these types.
Most Cray boxes don't have a two-byte type, for example, and some don't have
a 32-bit type.

> ...
> If you really prefer your proposal with specific sized types, perhaps
> you can show some coding example that would be easier using specific
> sizes rather than char/short/int/long/long long?

Since we can't promise to supply specific-sized types, let's cut that short.
You never need specific-sized types, and Python-Dev has had this argument
before.  Whenever it's come up, the code that relied on specific-sized types
got simpler after making it portable.  What you do need is a type *at least*
as big as the size you need in the end (and C99 has required typedefs for
that concept; Python could grow some too).