[Python-Dev] build problems under MSVC 5.0

[Trent Mick]

On Thu, Jun 29, 2000 at 12:07:42PM +0200, Fredrik Lundh wrote:
> Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier
> Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv'
> Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier
> Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type'
> Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier
> 
This is a result of one of my patches. I was using MSVC 6.0, where INT_PTR is
defined as you would expect. I did not realize that it was new to that
version of the headers.

BTW, INT_PTR, UINT_PTR, etc are the standard defines that I saw Microsoft
suggesting in their Win64 docs. I don't like those names, because they are
not portable. I should have used the (ANSI?) equivalents: intptr_t,
uintptr_t. In fact, I *did* use those in some of my patches where the code
portability was required (as obviously it is not in thread_*nt*.h).


> in MSVC 5.0, _beginthread returns an "unsigned long" (this is also
> how it's documented in MSDN).

Yup. And in the Win64 headers _beginthread returns uintptr_t, which makes me
wonder why I picked INT_PTR.


> 
> I suggest changing the declaration in thread_nt.h to:
> 
> #if _MSC_VER >= 1200
>  INT_PTR rv;
> #else
>  unsigned long rv;
> #endif
> 

As I said above, I acknowledge that I should not have used INT_PTR.
Win32: unsigned long _beginthread()
Win64: uintptr_t _beginthread()

I think (am I wrong?) to generalize that the intention for both Win32 and
Win64 is to have _beginthread return an unsigned pointer-sized integer: hence
uintptr_t.

This would eliminate the #ifdef but would require a typedef for uintptr_t on
Win32. This can be done in PC/config.h (I already did this for intptr_t,
because I needed *that* elsewhere.) Does this also need to be generalized to
typedef uintptr_t whereever it is not defined, i.e. in the autoconf files.

I can look at this this weekend, if that is soon enough.



> on the other hand, the same docs claim that it returns -1 on errors.
> doesn't exactly look like an unsigned long to me, but that's another
> story...
> 

Yes, strange.



Trent

-- 
Trent Mick
trentm@activestate.com