RFC: Cygwin 64 bit?

[Ryan Johnson]

On 28/06/2011 3:34 PM, Charles Wilson wrote:
> On 6/28/2011 2:49 PM, Corinna Vinschen wrote:
>> I still don't see the problem.  In how far is it valid to assume that
>> sizeof(long) == sizeof(LONG)?  long is a compiler intrinsic, LONG is
>> defined in a Windows header.  I don't see that the SDK claims that
>> there's a guarantee that long == LONG.  So, AFAICS, nothing speaks
>> against changing the w32api header to define LONG in a target dependent
>> way, for instance, and without gurantee for correctness:
>>
>>    #ifdef __X86_64__
>>    typedef int LONG;
>>    typedef unsigned int ULONG, DWORD;
>>    #else
>>    typedef long LONG;
>>    typedef unsigned long ULONG, DWORD;
>>    #endif
> In principle, I agree with you.  The worry is that one of the named apps
> is explicitly, in its own code, currently using 'long' to hold a value,
> which is passed to a w32api call where it gets converted (implicitly) to
> a LONG, DWORD, or void*.  Or vice versa.
Casting long <---> void* shouldn't be a problem if we go the linux way. 
The vice-versa direction shouldn't be a problem for the others because 
it would widen the value. That leaves long -> LONG and long -> DWORD.

Personally, I would never expect sizeof(DWORD)==8 because in x86 
assembly (the only other place where I encounter dwords) it is always a 
32-bit value. That leaves only long -> LONG (sample size one, YMMV, etc.)

In theory, at least, gcc should start generating warnings once long -> 
LONG becomes a narrowing conversion... unless a pre-existing explicit 
(LONG) cast shuts it up***. That should at least help.

*** or the function being called has been cast, or the function declared 
with implicit (= int) parameters, or any number of other abuses has 
occurred.

GCC is also pretty picky about format size modifiers for printf-like 
functions, particularly int vs. long (even when they are the same size). 
Unfortunately, LONG=long right now so people wouldn't have been getting 
yelled at up to this point.

One last thought, a question, actually: given that LONG is 32 bits in 
64-bit windows, and only the low 32-bits of handles are meaningful****, 
are there any obvious situations where losing the high 32 bits in a 
w32api call would cause unexpected behavior? The only one I can think of 
right off is size parameters which are not allowed to be larger than 
2^31-1, in which case wraparound would be a Bad Thing.

****how does that impact dll loading, BTW?

Thoughts?
Ryan