What GCC version had <stdint.h> defined?

[Scott David Daniels]

I am trying to figure out how to get 2.4a2 to build a python
extension. GCC 2.2.95 does not have a stdint.h, but 3.2.3 does.
These two are the only gcc versions I have on my box.

Does anyone know which version of GCC introduced stdint.h (and
thereby uintptr_t and intptr_t)? I'd like to get the conditionals
right.

-Scott David Daniels
Sc***********@Acm.Org

[Martin v. Löwis]

Scott David Daniels wrote:

Does anyone know which version of GCC introduced stdint.h (and
thereby uintptr_t and intptr_t)? I'd like to get the conditionals
right.

stdint.h is not part of GCC; it is part of libc6. You shouldn't do
#ifdefs based on version numbers, but instead, you should do checks
based on the features of the software, like autoconf does.

Regards,
Martin

[Scott David Daniels]

Martin v. Löwis wrote:

Scott David Daniels wrote:

Does anyone know which version of GCC introduced stdint.h (and
thereby uintptr_t and intptr_t)? I'd like to get the conditionals
right.

stdint.h is not part of GCC; it is part of libc6. You shouldn't do
#ifdefs based on version numbers, but instead, you should do checks
based on the features of the software, like autoconf does.

Regards,
Martin

Well, currently pyconfig.h for 2.4 says:
...
#if _MSC_VER != 1200
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif
...

which is actually a pretty low bar to get over.

I'd like to change it to something like:
...
#if _MSC_VER > 1200
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif
...
#if GCC_VERSION >= 30100
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif
...

which is arguably better even if not good enough.
Is there a better test I can do at compile time?

-Scott David Daniels
Sc***********@Acm.Org

[Jeff Epler]

I glanced at configure.in and it checks for HAVE_UINTPTR_T, but not
HAVE_INTPTR_T. If you want this define where it's available, add the
proper test to configure.in and regenerate configure.

I think the block would be something like this, a straightforward
search-and-replace of the block for HAVE_UINTPTR_T:
AC_MSG_CHECKING(for intptr_t support)
have_intptr_t=no
AC_TRY_COMPILE([], [intptr_t x; x = (intptr_t)0;], [
AC_DEFINE(HAVE_INTPTR_T, 1, [Define this if you have the type
intptr_t.])
have_intptr_t=yes
])
AC_MSG_RESULT($have_intptr_t)
if test "$have_intptr_t" = yes ; then
AC_CHECK_SIZEOF(intptr_t, 4)
fi
on the other hand, maybe this test is broken, because my system (Fedora
Core 2) configured with #undef HAVE_UINTPTR_T.

Maybe this article shows the way:
http://sources.redhat.com/ml/gdb-pat.../msg00687.html

AC_MSG_CHECKING(for uintptr_t in C library)
AC_CACHE_VAL(gdb_cv_have_uintptr_t,
[AC_TRY_COMPILE([#include <stdint.h>],
[uintptr_t foo = 0;
return foo;],
gdb_cv_have_uintptr_t=yes,
gdb_cv_have_uintptr_t=no)])
AC_MSG_RESULT($gdb_cv_have_uintptr_t)
if test $gdb_cv_have_uintptr_t = yes; then
AC_DEFINE(HAVE_UINTPTR_T)
fi
... with appropriate renaming for Python.

I'm not sure why uintptr_t or intptr_t are all that useful, since the
spellings "unsigned *" and "int *" are going to work everywhere anyway.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBLpviJd01MZaTXX0RAhrDAJ9O9ss+lXpcDRn5Q/r4ftGHPzDRCACgifvK
z5TGV6FUIFnmmtpp7tA2pg0=
=4FLF
-----END PGP SIGNATURE-----

[Tim Peters]

[Jeff Epler]
....

I'm not sure why uintptr_t or intptr_t are all that useful, since the
spellings "unsigned *" and "int *" are going to work everywhere
anyway.

intptr_t isn't a pointer type, it's a signed integer type wide enough
so that, for every valid void* P,

(void*)(intptr_t)P == P

C99 refuses to guarantee that such a type exists, but Python requires
one (and int, long or "long long" is big enough on all Python
platforms to date).

Similarly for uintptr_t.

[Scott David Daniels]

Jeff Epler wrote:

I glanced at configure.in and it checks for HAVE_UINTPTR_T, but not
HAVE_INTPTR_T. If you want this define where it's available, add the
proper test to configure.in and regenerate configure.

The problem is, of course (Billy G is always a problem), that I am running
on Win2K, so I don't run configure.in. I have two copies of MinGW --
one 2.95 (no stdint.h), and one 3.2.3 which does do stdint.h.
These were not set up when whoever built windows 2.3.4 did so -- he or
she did not know what was going to be on my disk after I downloaded and
installed python.

So, for me and my ilk ("isn't 'ilk' a lovely word" -- Albee), pyconfig.h
is a constant, not a calculated value.
-Scott David Daniels
Sc***********@Acm.Org

[Martin v. Löwis]

Scott David Daniels wrote:

I'd like to change it to something like:
...
#if _MSC_VER > 1200
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif
...
#if GCC_VERSION >= 30100
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif
...

which is arguably better even if not good enough.
That won't help at all. PC/pyconfig.h is used only
on Windows, not on Linux. On Linux, configure is run
to detect presence of things.
Is there a better test I can do at compile time?

Depends on what you want to test for. If it is
presence of stdint.h, you should test for
HAVE_STDINT_H.

Regards,
Martin

[Martin v. Löwis]

Scott David Daniels wrote:

The problem is, of course (Billy G is always a problem), that I am running
on Win2K, so I don't run configure.in. I have two copies of MinGW --
one 2.95 (no stdint.h), and one 3.2.3 which does do stdint.h.
These were not set up when whoever built windows 2.3.4 did so -- he or
she did not know what was going to be on my disk after I downloaded and
installed python.

Can you please explain what the problem is that you are trying to solve?
Apparently, it is not compiling Python.

If you are trying to compile a Python extension, can't you just check
for presence of /usr/include/stdint.h in setup.py?

But then, if you are compiling an extension - why do you even *need*
to know whether stdint.h is present?

Regards,
Martin

[Andrew MacIntyre]

On Thu, 26 Aug 2004, Scott David Daniels wrote:

The problem is, of course (Billy G is always a problem), that I am running
on Win2K, so I don't run configure.in. I have two copies of MinGW --
one 2.95 (no stdint.h), and one 3.2.3 which does do stdint.h.
These were not set up when whoever built windows 2.3.4 did so -- he or
she did not know what was going to be on my disk after I downloaded and
installed python.

In this context, stdint.h is not a part of gcc per se, but rather a
part of the MinGW development environment - in the same way that a lot of
other header files in MinGW's include directory are not part of the
standard gcc distribution.

If the module code in question can be built on Unixish platforms, ISTM
you should protect your special MinGW'isms with an #ifdef WIN32, to avoid
problems with Python installations built with configure.

The question that I think you are trying to ask is "which version of MinGW
introduced stdint.h", and then see if there's a define you can use...
(I don't know of one, but then I've only used MinGW 1.1 which contains gcc
2.95).

--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: an*****@bullseye.apana.org.au (pref) | Snail: PO Box 370
an*****@pcug.org.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia

[Scott David Daniels]

Martin v. Löwis wrote:

Scott David Daniels wrote:

I'd like to change it <pyconfig.h> to something like:
...
#if _MSC_VER > 1200
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif
...
#if GCC_VERSION >= 30100
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif
...
which is arguably better even if not good enough.

That won't help at all. PC/pyconfig.h is used only
on Windows, not on Linux. On Linux, configure is run
to detect presence of things.

Ah -- but my problem (which I was remiss in not describing well
enough) is just that I cannot compile _at_ _all_ on the Windows
box with minGW. I don't give a whit about <stdint.h> except to
try to make sure the proper definition happens. I'd like the
following extension to compile for 2.4 (it won't now) with MinGW:

#include <Python.h>

static PyMethodDef xyzMethods[] = {
{NULL, NULL, 0, NULL} /* Sentinel */
};

#if defined(PyMODINIT_FUNC)
PyMODINIT_FUNC
#else
void
#endif
initxyz(void)
{
PyObject *module = Py_InitModule("xyz", xyzMethods);
PyModule_AddStringConstant(module, "test", "value");
}

The error is roughly:
In file included from C:/python24/include/Python.h:55,
from xyzmodule.c:1:
C:/python24/include/pyport.h:69: parse error before "Py_uintptr_t"
C:/python24/include/pyport.h:69: warning: type defaults to `int'
in declaration of `Py_uintptr_t'
C:/python24/include/pyport.h:69: warning: data definition has
no type or storage class
C:/python24/include/pyport.h:70: parse error before "Py_intptr_t"
C:/python24/include/pyport.h:70: warning: type defaults to `int'
in declaration of `Py_intptr_t'
C:/python24/include/pyport.h:70: warning: data definition has
no type or storage class
error: command 'gcc' failed with exit status 1
That is, I don't even get to my _own_ broken code.
#if _MSC_VER > 1200
#define HAVE_UINTPTR_T 1 Is there a better test I can do at compile time?

Depends on what you want to test for. If it is
presence of stdint.h, you should test for
HAVE_STDINT_H.

Regards,
Martin

How is this as a change:

From this:
#ifdef MS_WIN32
...
/* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version
number of 1200. If some compiler does not provide them,
modify the #if appropriately. */
#if _MSC_VER != 1200
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif

#endif
To this:

#ifdef MS_WIN32
...
/* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version
number of 1200. If some compiler does not provide them,
modify the #if appropriately. */
#if _MSC_VER > 1200
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#elif HAVE_STDINT_H
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif

#endif
Or if HAVE_STDINT_H is defined under VC 7.1 (I cannot check that)
perhaps the change should become:

#ifdef MS_WIN32
...

#if HAVE_STDINT_H
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#endif

#endif

In any case, thanks for the help so far.

-Scott David Daniels
Sc***********@Acm.Org

[Scott David Daniels]

I've submitted patch # 1020042 for this problem.