Mark Dickinson added the comment:
Here's a patch (against the default branch). It adds simple AC_CHECK_TYPE
configure-time typechecks for uint32_t and friends.
--
Added file: http://bugs.python.org/file28185/issue10052.patch
___
Python tracker
Roundup Robot added the comment:
New changeset 6f9aba5f8d32 by Mark Dickinson in branch 'default':
Issue 10052: fix failed uint32_t / uint64_t / int32_t / int64_t detection on
some platforms.
http://hg.python.org/cpython/rev/6f9aba5f8d32
--
nosy: +python-dev
Mark Dickinson added the comment:
Committed to default. I want to look at the buildbot results and try some
manual snakebite tests before deciding whether to backport.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
Roundup Robot added the comment:
New changeset 48fbe78167cd by Mark Dickinson in branch '2.7':
Issue 10052: fix failed uint32_t / uint64_t / int32_t / int64_t detection on
some platforms.
http://hg.python.org/cpython/rev/48fbe78167cd
--
___
Python
Roundup Robot added the comment:
New changeset d82b73366227 by Mark Dickinson in branch '3.2':
Issue 10052: fix failed uint32_t / uint64_t / int32_t / int64_t detection on
some platforms.
http://hg.python.org/cpython/rev/d82b73366227
New changeset 48de792747dc by Mark Dickinson in branch
Mark Dickinson added the comment:
Fixed in all branches.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
___
Changes by Trent Nelson tr...@snakebite.org:
--
nosy: +trent
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
___
___
Python-bugs-list mailing
Mark Dickinson added the comment:
This is also an issue on the Tru64 / alpha on Snakebite: that platform has
inttypes.h but no stdint.h, and inttypes.h has typedefs for uint32_t and
friends, but no defines for UINT32_MAX, etc. So the pyport.h check:
#if (defined UINT32_MAX || defined
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
___
___
Changes by Mark Dickinson dicki...@gmail.com:
--
versions: +Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
___
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
stage: - patch review
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
___
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the patch. This looks fine, in principle.
A couple of comments and questions:
(1) I think the patch should provide *MIN values alongside the *MAX values (for
signed types only, of course).
(2) Are we sure that these values are
Akira Kitada akit...@gmail.com added the comment:
This patch is specifically targeted at FreeBSD 4.
tested on FreeBSD 4.11 and OS X 10.6.4
I don't know how to accommodate SGI IRIX's case.
--
keywords: +patch
Added file: http://bugs.python.org/file19254/issue10052.diff
Tom O'Connor ichasepu...@gmail.com added the comment:
Same problem on SGI IRIX 6.5.28 GCC 3.3.
Adding the following to pyport.h got me through as well.
#define UINT32_MAX 0x
#define INT32_MAX 0x7fff
--
nosy: +Tom.OConnor
___
Python
Mark Dickinson dicki...@gmail.com added the comment:
Anyway, I would like to leave the decision to the core developers.
You mean the core developers other than Stefan? ;-)
I don't have any objection to a patch for this problem, provided that that
patch is specifically targeted at FreeBSD 4,
Akira Kitada akit...@gmail.com added the comment:
Forgot to mention that there's no _MAX macro for exact-width integer types.
$ egrep -r 'INT[0-9].*_MAX' /usr/include/ | wc -l
0
How about adding those macros when the system does not provide them?
--
Stefan Krah stefan-use...@bytereef.org added the comment:
FreeBSD 5.0 has stdint.h, which includes machine/_stdint.h. In the
latter file the *_MAX constants are defined.
It looks like FreeBSD has had the correct setup for more than 7 years:
Akira Kitada akit...@gmail.com added the comment:
I understand FreeBSD 4.x is old platform (4.11, the last 4.x series, is
released 5 years ago) but, in my opinion, as long as it does not make Python
code cluttered, supporting old platforms is not that bad idea.
Anyway, I would like to leave
New submission from Akira Kitada akit...@gmail.com:
Building Python 2.7 fails on FreeBSD 4.11 with gcc 2.95.4 as below:
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o
Python/dtoa.o Python/dtoa.c
Changes by Eric Smith e...@trueblade.com:
--
nosy: +eric.smith, mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the report. Some questions:
1. Have you tested this with Python 3.x at all? I'd expect the same issues to
show up for Python 3.1 and 3.2.
2. Also, do you have the relevant configure output to hand? On my machine, the
output
Akira Kitada akit...@gmail.com added the comment:
1. Have you tested this with Python 3.x at all? I'd expect the same issues
to show up for Python 3.1 and 3.2.
Yes, I can reproduce this in 2.7, 3.1 and 3.2.
2. Also, do you have the relevant configure output to hand? On my machine,
the
22 matches
Mail list logo
