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

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


Corinna

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


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