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/2002-November/030532.html below:

[Python-Dev] int/long FutureWarning

[Python-Dev] int/long FutureWarningMartin v. Löwis martin@v.loewis.de
28 Nov 2002 11:48:46 +0100
"M.-A. Lemburg" <mal@lemburg.com> writes:

> > Can you please explain how this will happen? If you do   int x;
> >   PyArg_ParseTuple(args,"i",&x);
> > and args is (0x80000000,), what will be the value of x?
> 
> x should be 0x80000000. Whether that's a negative number in
> its decimal representation is really not all that important if
> you are interfacing to 32-bit bitmaps ;-)

This was not my question. I asked what the value *will* be, not what
it *should* be. Can you answer the first question (how will this
happen)?

> I honestly don't think that anyone would write x = 0x80000000
> and then expect x < 0 to be True. People usually write hex
> representations when they are trying to do bit-level manipulations
> and these rarely deal with signed numeric data.

I agree with all that. However, I cannot see how an actual
implementation works that simultaneously meets all implied
requirements:
- integer constants are always positive; you get negative numbers
  only with a unary "-".
- ParseTuple continues to raise OverflowErrors for values that
  are out of range.
- The constant 0x80000000 has the same trailing 32 bits in the
  C int or long as it has in Python.

Regards,
Martin



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