At 02:17 PM 6/27/2002, Jim Jagielski wrote:
I'm still slogging through tons of email, but was the issue that
it was simply 'long' instead of 'int' (and trusting that the platform/OS
correctly handles things) or that we require a specific physical
size?
Ours is simply a HANDLE. End of issue for this platform :-)
FWIW, the current 2.0 implementation is copied from 1.3, so if it's
wrong in one, it's wrong in the other. Also, in other implementations
I've seen, it's always used 'int' and not 'long' so the current
usage seems wrong to me. :/
Agreed, for this type. Just making a 32/64 bit ambiguity observation :-)
At 1:11 PM -0500 6/27/02, William A. Rowe, Jr. wrote:
>At 01:00 PM 6/27/2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
>>Yep - with HP-UX running on 64-bit Itanium, and using the 64-bit data
model.
>>The side effect of having the "long val" in the union definition is that
>>it'll have corrupted the mutex/semaphore while creating the proc_mutex
>>itself (proc_mutex_sysv_create). On HP-UX, the symptom was that the
>>listener_thread hangs while doing a SAFE_ACCEPT.
>
>AFAICT, the only exception is win32, which retains the 32 bit int, 64
bit memory
>pointer, 64 bit 'INT_PTR' meaning that it could wrap an int or pointer.
>
>This appears to apply to _NO_ unix architectures, so int should be correct.
>We could create an ap_intptr_t that does the same, with;
>
>typedef union ap_intptr_t {
> int i;
> int *p;
>} ap_intptr_t;
>
>and take ap_intptr_t or sizeof(ap_intptr_t) when we need an object
>that safely maps either and both.
>
>Bill
--
===========================================================================
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
