"Alon Bar-Lev" <alon.barlev@gm...> wrote on 20.10.2008 16:07:51:
> Is there any reason why alarm() prototype is declared for win64? It is
> not available for Windows anyway... :)
No, the declaration of alarm is an relict. In earlier stage we defined a
dummy crt version of this POSIX function. Maybe you could file a bug in sf
tracker for it. So I don't miss to remove it.
Maybe same for pid_t at sys/types.h
It is not Windows type and is not used anyway as far as I can see.
Fixed at revision 479.
The pid_t is quite necessary for a successful bootstrap of the gnu toolchain. Therefore I put it into the headers. I agree that this type doesn't exists (as far as msdn tells), but it doesn't hurt and prevents wrong assumptions.
Thanks for reporting.
For the pid_t... Some win32 applications, such as OpenSSL declares their own pid_t for win32.
So there is a conflict.
As far as I can see the conflict was not there in mingw32...
Maybe there is a way to do it for bootstrap only? There is a define?
Hmm, well. IMHO this is more a bug in such libraries for not testing the existance of a POSIX type. But maybe it would be helpful here to make the declaration conditional. So a library, which prefers to declare pid_t by itself, can define pid_t to my_pid_t - before including the headers. The other way it could be solved is, to typedef pid_t as wished and define _PID_T_ before including the headers.
Ah, ok :) I see. mingw defines pid_t, too. But the macro to disable the so called *old* names is different between mingw and mingw-w64. For old mingw it is _NO_OLDNAMES, for mingw-w64 it is just NO_OLDNAMES, as msdn mention it.
What about the signal.h and unused signals?
Such as SIGALRM?
mingw32 had only subset of signals...
Kai, can you please address the signals issue?
I wish to submit patches for OpenSSL, and I know this issue should be resolved before.
I fixed the issue about SIGALRM in signal.h, too. See revision 483. I made the define dependent to the macro __USE_MINGW_ALARM, which is by default not defined.
I hope this helps :)