RFC: Cygwin 64 bit?
Ryan Johnson
ryan.johnson@cs.utoronto.ca
Tue Jun 28 21:05:00 GMT 2011
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
More information about the Cygwin-developers
mailing list