RE: [bug #27809] several win64 fixes

[Martin Dorey]

> why can't you get rid of the cast altogether

Because there is no implicit conversion from pointer to integer.

> users of MinGW will then complain about compiler warnings, right?

Because of an implicit conversion from unsigned int (the definition of
uintptr_t on w32) to long, on a platform where both types are the same
size?  That seems unlikely.

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of Eli
Zaretskii
Sent: Monday, October 26, 2009 13:47
To: address@hidden; address@hidden; address@hidden;
address@hidden
Subject: Re: [bug #27809] several win64 fixes

> From: Ozkan Sezer <address@hidden>
> Date: Mon, 26 Oct 2009 19:20:27 +0000
> 
> 
> > 3. Why did you need casts in assignments, like this:
> >
> > -    *pid_p = (int) hProcess;
> > +    *pid_p = (pid_t) hProcess;
> >
> 
> Because you are casting a handle, which is a ptr*,  to an int.

But you change pid_p to point to a pid_t type, which is no longer an
int on a 64-bit host.  So why can't you get rid of the cast
altogether, like this:

   pid_p = hProcess;

?  Does this work on w64?

> > 4. This change:
> >
> > -  pipedes[0] = _open_osfhandle((long) hChildOutRd, O_RDONLY);
> > +  pipedes[0] = _open_osfhandle((intptr_t) hChildOutRd, O_RDONLY);
> >
> > assumes that _open_osfhandle accepts an intptr_t type as its first
> argument.
> > But the prototype I have on my machine (in io.h) says the first
argument is
> a
> > `long'.  Which version of MinGW changed that?
> 
> It is the same case.  Your version is for w32-only.
> The mingw-w64 version is like (from io.h):
> _CRTIMP int __cdecl _open_osfhandle(intptr_t _OSFileHandle,int
_Flags);

But that means I cannot simply apply your patch, because users of
MinGW will then complain about compiler warnings, right?

Thanks for the other info.


_______________________________________________
Bug-make mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-make