build problems under MSVC 5.0
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 in MSVC 5.0, _beginthread returns an "unsigned long" (this is also how it's documented in MSDN). I suggest changing the declaration in thread_nt.h to: #if _MSC_VER >= 1200 INT_PTR rv; #else unsigned long rv; #endif 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... </F>
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
trent wrote:
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.
I suggest checking in the #ifdef as a stopgap measure, if you promise to come up with the right thing (whatever that is) in time for 1.6 final. Should I go ahead and check it in? </F>
On Thu, Jun 29, 2000 at 07:07:02PM +0200, Fredrik Lundh wrote:
trent wrote:
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.
I suggest checking in the #ifdef as a stopgap measure, if you promise to come up with the right thing (whatever that is) in time for 1.6 final.
Should I go ahead and check it in?
Fredrik, I have put the "right thing" (I hope) up on SourceForge and assigned it to you: http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470 I explained what I think is the right idea in the preceeding email in this thread: http://www.python.org/pipermail/python-dev/2000-June/011800.html Could you try the patch and then assign it back to me for check in? (Or just check it in yourself) Thanks, Trent -- Trent Mick TrentM@ActiveState.com
participants (2)
-
Fredrik Lundh -
Trent Mick