[Patches] [ python-Patches-1020042 ] Bad test for HAVE_UINTPTR_T in PC/pyconfig.h

SourceForge.net noreply at sourceforge.net
Wed Sep 1 00:08:28 CEST 2004


Patches item #1020042, was opened at 2004-08-31 22:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020042&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott David Daniels (scott_daniels)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad test for HAVE_UINTPTR_T in PC/pyconfig.h

Initial Comment:
In python 2.4.a2 on Win2K, 
There is a test (encased in an "#if MS_WIN32" block) 
that goes awry.  

The original code (around line 270 of PC/pyconfig.h) is:

/* 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

MinGW has trouble compiling with this code.  Unless 
you have VC 6.0, this presumes you have uintptr_t 
and intptr_t available.  From what I can find out 
(including a message from MvL), I believe the code 
should really be:

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

However, I don't have VC 7.1 to test this theory out.
A more conservative change would be to:

#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

Essentially, the problem is whether a type name has 
been defined or not.  The C99 standard dictates that 
the types uintptr_t and intptr_t be available through
#include <stdint.h>.  Some systems have stdint.h,
others don't.  Old MinGW systems do not (e.g. 2.95); 
new ones do (e.g. 3.2.3).  Martin von Loewis tells me
the library libc6 is responsible for having this file or 
not, so it is not really a compiler thing at all.

HAVE_STDINT_H should cover all  cases.  If you can
install python 2.4 and compile (with distlib) _any_
C extension, that compiler (the one used by distlib)
works correctly.  When the problem occurs, the C
compiler fails inside declarations included by Python.h.
I've tried this with the MinGW 2.95 and 3.2.3.
Even changing the 
    #if _MSC_VER != 1200
to 
    #if _MSC_VER > 1200
is good enough (C preprocessing rules make undefined 
_MSC_VER != 1200 behave unfortunately) to work, but
_if_ the STDINT_H version works for VC 6.0 and 7.1,
I favor that (it is testing the correct thing).

If _any_ C extension can be successfully compiled on
a windows box using the distributed pyconfig.h and a
particular compiler, the problem has been solved for 
that compiler.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020042&group_id=5470


More information about the Patches mailing list