This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Bad test for HAVE_UINTPTR_T in PC/pyconfig.h
Type: Stage:
Components: Interpreter Core Versions: Python 2.4
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: loewis, scott_daniels
Priority: normal Keywords: patch

Created on 2004-08-31 22:08 by scott_daniels, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg46815 - (view) Author: Scott David Daniels (scott_daniels) * Date: 2004-08-31 22:08
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.
msg46816 - (view) Author: Scott David Daniels (scott_daniels) * Date: 2004-09-13 19:29
Logged In: YES 
user_id=493818

To expand a bit on C preprocessing rules make undefined
_MSC_VER != 1200 behave unfortunately, if _MSC_VER is 
undefined:
    #if _MSC_VER != 1200
becomes:
    #if 0 != 1200
And so takes the branch for all C compilers except VC 6.0
msg46817 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-10-15 04:26
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as pyconfig.h 1.31.
History
Date User Action Args
2022-04-11 14:56:06adminsetgithub: 40851
2004-08-31 22:08:28scott_danielscreate