[issue17884] Try to reuse stdint.h types like int32_t

[Stefan Krah]

Stefan Krah added the comment:

Probably this one: #23545

--
nosy: +skrah
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[SilentGhost]

Changes by SilentGhost :


--
resolution:  -> fixed
stage:  -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy:  -pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[SilentGhost]

SilentGhost added the comment:

Probably, not for a particularly good reason, but none of the near-by code in 
_ssl.c seemed relevant on superficial inspection. The commit 02c8db9c255f which 
modified Include/pymem.h didn't have an issue associated with it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

STINNER Victor added the comment:

> I get the following compiler warning now: (...)

Why do you think that it's related to stdint.h changes?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[SilentGhost]

Changes by SilentGhost :


--
resolution: fixed -> 
stage: patch review -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[SilentGhost]

SilentGhost added the comment:

I get the following compiler warning now:

In file included from ./Include/Python.h:66:0,
 from /cpython/Modules/_ssl.c:19:
/cpython/Modules/_ssl.c: In function ‘_setup_ssl_threads’:
./Include/pymem.h:136:18: warning: comparison is always false due to limited 
range of data type [-Wtype-limits]
   ( ((size_t)(n) > PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
  ^
/cpython/Modules/_ssl.c:5076:22: note: in expansion of macro ‘PyMem_New’
 _ssl_locks = PyMem_New(PyThread_type_lock, _ssl_locks_count);
  ^

--
nosy: +SilentGhost
versions: +Python 3.6 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1d29d3a1e0c6 by Victor Stinner in branch 'default':
Run Argument Clinic on posixmodule.c
https://hg.python.org/cpython/rev/1d29d3a1e0c6

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Benjamin Peterson]

Benjamin Peterson added the comment:

Thank you all for your advice. The buildbots seem to have survived the removal 
of conditional includes of . I've also replaced most of the Python 
compatibility aliases with the standard ones. Closing this issue.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Roundup Robot]

Roundup Robot added the comment:

New changeset be8645213517 by Benjamin Peterson in branch 'default':
replace Python aliases for standard integer types with the standard integer 
types (#17884)
https://hg.python.org/cpython/rev/be8645213517

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Roundup Robot]

Roundup Robot added the comment:

New changeset c092eb31db05 by Benjamin Peterson in branch 'default':
only include inttypes.h (#17884)
https://hg.python.org/cpython/rev/c092eb31db05

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Include/pyport.h now includes both  and . But the 
 header shall include the  header. [1]

[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/inttypes.h.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8b74e5528f35 by Benjamin Peterson in branch 'default':
dtoa.c: remove code for platforms with 64-bit integers (#17884)
https://hg.python.org/cpython/rev/8b74e5528f35

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

Good point. I'd be happy to see the non-"#ifdef ULLong" branches simply 
disappear in dtoa.c. We're long past the point of trying to keep dtoa.c in sync 
with the upstream version.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Python/dtoa.c contains a number of "#ifdef ULLong". Since now ULLong is not a 
macro but a typedef, this condition is false and the compiler now compiles 
different (less efficient and perhaps less tested) branch of the code.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

LVGTM, if the buildbots agree.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Roundup Robot]

Roundup Robot added the comment:

New changeset ae03163b6378 by Benjamin Peterson in branch 'default':
require standard int types to be defined (#17884)
https://hg.python.org/cpython/rev/ae03163b6378

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Benjamin Peterson]

Benjamin Peterson added the comment:

In 3.6, I just deprecated support for platforms without "long long". 
https://bugs.python.org/issue27961 "deprecated" is a strong word because I 
couldn't actually find a modern Python version that compiles without it. I'm 
informed that the MSVC we're since 3.5 will have stdint.h available. I think we 
should start requiring it.

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Antoine Pitrou]

Antoine Pitrou added the comment:

I'm in favour of trying this in 3.5. A platform not supporting those types 
would not be able to run a lot of contemporary software, I think.

--
nosy: +pitrou
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +belopolsky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Stefan Krah]

Changes by Stefan Krah :


--
nosy:  -skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Guido Draheim 2011]

Guido Draheim 2011 added the comment:

Relicensing to Python core from my Opensource-licensed material is always 
permitted, including ax_create_stdint_h.m4

--
nosy: +guidod-2011

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

> According to what you wrote above, uint32_t can always be used on any
> platform.

The issue is in *detecting* whether uint32_t exists or not.  In cases (1) and 
(3), that can be done in the preprocessor with an "#ifdef uint32_t".  In case 
(2), it can't: the check fails, because uint32_t isn't a preprocessor 
define---it's a typedef.  *That's* why we need the HAVE_UINT32_T check.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

STINNER Victor added the comment:

2013/5/6 Mark Dickinson :
> Concentrating on uint32_t for specificity, there are essentially three cases:
>
> (1) The platform (either in stdint.h or inttypes.h) #defines uint32_t.
>
> (2) The platform (either in stdint.h or inttypes.h) makes a typedef for 
> uint32_t.
>
> (3) The platform doesn't do (1) *or* (2), but nevertheless, there's an 
> unsigned integer type that has exact 32-bit width (and it's probably called 
> "unsigned int").

So in all these 3 cases, it is possible to use "uint32_t" in the code.

> [Oh, and (4) Windows.  Let's leave that out of this discussion, since there 
> don't seem to be any Windows-specific problems in practice here, and we don't 
> use autoconf.]

Windows issues can be fixed in PC/pyconfig.h.

> So cases (1) and (3) lead to uint32_t being #defined, while cases (1) and (2) 
> lead to HAVE_UINT32_T being defined.  We want to catch all 3 cases, so we 
> have to check for *both* uint32_t and HAVE_UINT32_T in pyport.h.

Sorry I still don't understand why do you need HAVE_UINT32_T define.
According to what you wrote above, uint32_t can always be used on any
platform.

> Note that using AC_TYPE_UINT32_T and checking whether uint32_t is defined is 
> not enough on platforms that do (2): because uint32_t is a typedef rather 
> than a #define, there's no easy way for pyport.h to find it.  Prior to the 
> issue #10052 fix, we assumed that any platform doing (2) would, following 
> C99, also define UINT32_MAX, but that turned out not to be true on some 
> badly-behaved platforms.

Why should Python do extra checks in pyport.h (ex: check if UINT32_MAX
is available)? Can't we rely on stdint.h?

If stdint.h is not available, we can ask configure to build it for us
using AX_CREATE_STDINT_H. Oh, it looks like this macro is not part of
autotools directly. It's a third party module released under the GNU
GPLv3+ license. Can we include a GPL script in our tool chain? I
contacted the author by email to ask him if we can distribute it under
a different license (compatible with the Python license).

http://www.gnu.org/software/autoconf-archive/ax_create_stdint_h.html
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_create_stdint_h.m4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

Stefan:  sounds reasonable.  I'd be happy to make availability of exact-width 
32-bit and 64-bit, signed and unsigned integer types a requirement for building 
Python, provided that we run that by the python-dev mailing list first.  I 
agree that this is what we seem to be doing in practice anyway, so we'd just be 
codifying existing practice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

[Victor]

> Ok, I think I understood the issue :-) The problem is when the uint32_t
> type is present but is not exactly 32-bit width.

No, that's still not the issue :-). In any case, it would be a fairly serious 
violation of C99 to use uint32_t for something that *wasn't* exactly 32 bits in 
width.  More generally, padding bits, trap representations, and non two's 
complement representations for signed integers seem to be a thing of the past;  
having integer types be exact width seems to be one of the few things that we 
*can* reasonably rely on.

Concentrating on uint32_t for specificity, there are essentially three cases:

(1) The platform (either in stdint.h or inttypes.h) #defines uint32_t.

(2) The platform (either in stdint.h or inttypes.h) makes a typedef for 
uint32_t.

(3) The platform doesn't do (1) *or* (2), but nevertheless, there's an unsigned 
integer type that has exact 32-bit width (and it's probably called "unsigned 
int").

[Oh, and (4) Windows.  Let's leave that out of this discussion, since there 
don't seem to be any Windows-specific problems in practice here, and we don't 
use autoconf.]


We've encountered all three of these cases, and as far as I know in recent 
history we haven't encountered a platform that doesn't match at least one of 
these three cases.

With respect to the autoconf and pyport machinery:

In case (1): AC_TYPE_UINT32_T does nothing, because uint32_t is already 
available, while the
AC_CHECK_TYPE(uint32_t) #defines HAVE_UINT32_T.

In case (2): AC_TYPE_UINT32_T still does nothing, and again 
AC_CHECK_TYPE(uint32_t) #defines HAVE_UINT32_T.

In case (3): AC_TYPE_UINT32_T #defines uint32_t to be the appropriate type, and 
AC_CHECK_TYPE(uint32_t) will fail.

So cases (1) and (3) lead to uint32_t being #defined, while cases (1) and (2) 
lead to HAVE_UINT32_T being defined.  We want to catch all 3 cases, so we have 
to check for *both* uint32_t and HAVE_UINT32_T in pyport.h.


Note that using AC_TYPE_UINT32_T and checking whether uint32_t is defined is 
not enough on platforms that do (2): because uint32_t is a typedef rather than 
a #define, there's no easy way for pyport.h to find it.  Prior to the issue 
#10052 fix, we assumed that any platform doing (2) would, following C99, also 
define UINT32_MAX, but that turned out not to be true on some badly-behaved 
platforms.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Stefan Krah]

Stefan Krah added the comment:

Mark Dickinson  wrote:
> There's also some cleanup to be done with respect to semantics;  I think it's 
> still the case that the various PyLong_FromXXX functions have different 
> behaviours with respect to overflow, __int__, __index__ and the like.  If we 
> just blindly map the old functions to the fixed-width versions we're going to 
> end up changing those semantics on some platforms.

That could be a problem. It's tempting though, since we'd finally have
a uniform behavior for the PyLong_FromXXX functions (#12965).

> I'd be quite happy to see fixed-width conversion functions that *completely 
> ignore* __int__ and __index__, and leave the magic stuff to general 
> PyNumber_... functions.

Definitely.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Stefan Krah]

Stefan Krah added the comment:

Mark Dickinson  wrote:
> No idea.  Do you have good evidence that 64-bit integer types *will* be
> supported on all platforms that we care about Python compiling on?

I'm not sure how many people have tried to compile Python 3.3 on obscure
platforms, but libmpdec currently requires manual intervention to switch
on the "without uint64_t" mode:

/* The following #error is just a warning. If the compiler indeed does
 * not have uint64_t, it is perfectly safe to comment out the #error. */
#error "Warning: Compiler without uint64_t. Comment out this line."

I did this because I'm almost certain that a failure to detect uint64_t is
more likely a ./configure issue than an actual absence of the type.

So far there have been no reports. libmpdec also uses stdint.h directly,
and there haven't been any reports either.

Some commercial Unix buildbots have loads of problems, but support stdint.h,
static inline functions in headers and even the tricky extern inline
C99 functions (See: http://www.greenend.org.uk/rjk/tech/inline.html).

If other developers support it, I'd actually like to write a PEP that allows
unrestricted direct use of stdint.h and static inline functions in header files
for Python 3.4.

My gut feeling is that if a platform doesn't have these features, it will
likely be the least of their problems.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

STINNER Victor added the comment:

Ok, I think I understood the issue :-) The problem is when the uint32_t type is 
present but is not exactly 32-bit width. When using uint32_t, *I* expect that 
an array of uint32_t items will takes 4 x n bytes. In which case is it 
interesting to use an uint32_t which may be bigger? If there is an use case 
(speed maybe?), we should define a Py_uint32_t which is always present and 
always exaclty 32 bits. If there is no use case (ex: int_fast32_t or 
int_least32_t can be used instead), it is maybe better to replace the available 
type using a #define to use the expect type.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

> I don't understand. Python is already using 64-bit types, in md5
> module for example (MD5_INT64). This module is not compiled on ARM?

No idea.  Do you have good evidence that 64-bit integer types *will* be 
supported on all platforms that we care about Python compiling on?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

> I don't understand why "#ifdef HAVE_UINT32_T" is tested, since configure 
> ensures that uint32_t is always defined.

Take a look at the explanations in the autoconf file and in pyport.h.  No, 
configure does *not* always ensure that uint32_t is defined:  it does that only 
if the platform *doesn't* provide uint32_t, but does provide a 32-bit 
exact-width unsigned integer type (two's complement, no padding bits, etc. 
etc.).  Which is why we need to make a second check for the case that the 
platform *does* define uint32_t directly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

STINNER Victor added the comment:

> I *think* that since the issue #10052 fix, the current autoconf
> machinery is now fairly good at finding those types across platforms,
> but I wouldn't want to make any bets.

The issue #10052 was not that the int32_t was not present, but an #ifdef issue: 
"This error occurs when HAVE_UINT32_T or HAVE_INT32_T are not defined".

I don't understand why "#ifdef HAVE_UINT32_T" is tested, since configure 
ensures that uint32_t is always defined. (If it is not, it is defined in 
pyconfig.h using a #define.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

STINNER Victor added the comment:

"Relying on things like int64_t or uint64_t is tricky, both in
principle *and* in practice. (...) uint64_t and int64_t may be a
stretch, particularly on ARM-style platforms."

I don't understand. Python is already using 64-bit types, in md5
module for example (MD5_INT64). This module is not compiled on ARM?

"In practice, we've had significant difficulties in the past simply
finding and identifying exact-width types in our autoconf machinery:
whether they're defined in  or  seems to vary
from platform to platform, as does whether they're defined as
typedef's or preprocessor macros."

I don't understand. AC_TYPE_UINT64_T is supposed to provide the
uint64_t (unsigned integer of 64-bit).

Autotool can also generate the stdint.h header if it is not available.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Devin Jeanpierre]

Devin Jeanpierre added the comment:

I don't know what context these types are being used in, but would 
int_least64_t suffice? C99 does require the existence of the [u]int_leastN_t 
types (for N in {8,16,32,64}), unlike [u]intN_t.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[Mark Dickinson]

Mark Dickinson added the comment:

Relying on things like int64_t or uint64_t is tricky, both in principle *and* 
in practice.

C99 (7.18.1.1) specifies that the types are optional, but that if the 
implementation provides types with the appropriate characteristics then the 
typenames should exist.  I think we could probably get away with assuming the 
existence of uint32_t and int32_t and smaller types, but uint64_t and int64_t 
may be a stretch, particularly on ARM-style platforms.

In practice, we've had significant difficulties in the past simply finding and 
identifying exact-width types in our autoconf machinery:  whether they're 
defined in  or  seems to vary from platform to platform, 
as does whether they're defined as typedef's or preprocessor macros.  I *think* 
that since the issue #10052 fix, the current autoconf machinery is now fairly 
good at finding those types across platforms, but I wouldn't want to make any 
bets.

I do agree that in principle it would be nice to define conversions for the 
fixed-width types and have everything else defer to those.

There's also some cleanup to be done with respect to semantics;  I think it's 
still the case that the various PyLong_FromXXX functions have different 
behaviours with respect to overflow, __int__, __index__ and the like.  If we 
just blindly map the old functions to the fixed-width versions we're going to 
end up changing those semantics on some platforms.

I'd be quite happy to see fixed-width conversion functions that *completely 
ignore* __int__ and __index__, and leave the magic stuff to general 
PyNumber_... functions.

Adding skrah to the nosy, since this is something I think he's spent some time 
thinking about, too.

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

STINNER Victor added the comment:

See also issue #17870 related to intmax_t and uintmax_t.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

New submission from STINNER Victor:

In different places, macros like SIZEOF_VOID_P or SIZEOF_LONG to choose a type, 
whereas the C language proposes standard types since ISO C99: intXX_t and 
uintXX_t (8, 16, 32, 64), intptr_t, etc.

Python should rely on these new types instead of trying to reimplement this 
standard. autotools provides missing types if needed. On Windows, stdint.h is 
supported in Microsoft Visual Studio 2010.

Attached patch reuses stdint.h types in different places. I only tested it on 
Linux Fedora 11.

sha3 module should also be modified.

I don't know if int64_t and uint64_t are always supported, nor if we can rely 
on them. Does Python support platform without 64-bit integer type?

The md5 module uses PY_LONG_LONG to get a 64-bit type. Does anyone know a 
platform where the md5 module is not compiled?

--
files: reuse_stdint_types.patch
keywords: patch
messages: 188192
nosy: Devin Jeanpierre, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Try to reuse stdint.h types like int32_t
versions: Python 3.4
Added file: http://bugs.python.org/file30083/reuse_stdint_types.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com