This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Cygwin 64 bit?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]