This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
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