RFC: Cygwin 64 bit?

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Jun 29 07:31:00 GMT 2011

On Jun 28 17:05, Ryan Johnson wrote:
> On 28/06/2011 3:34 PM, Charles Wilson wrote:
> >On 6/28/2011 2:49 PM, Corinna Vinschen wrote:
> >>   #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.

This might turn out to be a bad idea.

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

I remember with some fondness the times when I switched from 32 bit
Linux to 64 bit Linux.  One of these days I wrote some testcase,
business as usual:

  #include <stdio.h>
  #include <errno.h>

  main ()
    int fd = open ("foo", O_RDWR);
    if (fd < 0)
      	fprintf (stderr, "open: %d <%s>\n", errno, strerror (errno));
	return 1;

When open failed, the testcase did not print an error message, it
crashed.  It took some time to puzzle out that strerror returned a 64
bit pointer, but only 32 bit of the pointer were given as argument to
fprintf.  Why?  I missed to include string.h, so strerror was treated as
a function returning an int.  That was when I learned not to ignore the
gcc warning "implicit declaration of function ‘foo’".

I still don't see a problem.  LONG is a Win32 type, long is a compiler
defined type.  And -Wall helps a lot.

> 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?

Sign extension could cause a problem.  I don't think HANDLEs are a
problem since you usually don't store HANDLEs in longs or ints.  Even
though HANDLEs are defines as void *, they are not really pointers in
the usual sense.  If anything, "real" pointers are a problem.

However, as my above example shows, you could get into the same kind of
problems on Linux.  Developers get over it.  They should be able to do
the same when calling Win32 functions.

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

No.  Should it?  Do you have an example to show what you're concerned


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list