apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject RE: [PATCH] Regarding semun definition in proc_mutex.h
Date Thu, 27 Jun 2002 19:17:04 GMT
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?

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. :/

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   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson

Mime
View raw message