[bug #27809] several win64 fixes

[Ozkan Sezer]

Follow-up Comment #4, bug #27809 (project make):

[ I forgot replying from within the bug tracker.
  sorry if this becomes a duplicate. ]

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

Well,

typedef struct _PROCESS_INFORMATION {
 HANDLE hProcess;
 HANDLE hThread;
 DWORD dwProcessId;
 DWORD dwThreadId;
} PROCESS_INFORMATION,*PPROCESS_INFORMATION,*LPPROCESS_INFORMATION;

hProcess is HANDLE here, but your pid_p is int in your
original version or pid_t in my version.  Without casting
you'll get warnings from the compiler.

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

How so??  MinGW does provide intptr_t, I really can't see the
problem here.

and, for the record, I just built the make-cvs for mingw.org,
without and with my patch applied, there seems to be no new
warnings generated (and many of the alloca warnings are just
cured.)  Attaching a diff of build logs.

>>
>> -mthreads :  This one is a noop for mingw-w64 crt.
>
> This is needed to properly handle Ctrl-C, since (at least on w32) the
> signal handler runs in a separate thread.  So what happens in a w64
> build of Make if you press Ctrl-C while Make runs?  Does it behave as
> expected (read: as on Posix systems)?
>

Just tried running a makefile with it (under an msys console) and it
just exists.

> Thanks for the other info.
>

My pleasure.

--
Ozkan


(file #18947)
    _______________________________________________________

Additional Item Attachment:

File name: mingw-buildlogs-diff.txt       Size:15 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27809>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/