22 Aug
2007
22 Aug
'07
2:21 p.m.
KJK::Hyperion wrote:
So this is a MinGW bug, where not hosts are created equal. Isn't it?
Kind of.
The mingw-runtime contains some files like "stdio.h", which include
"stddef.h". But mingw-runtime does not contain any "stddef.h" file, so
GCC's
fixincludes tool copies it from the host.
wchar_t must not depend on the host.
Only for the target compiler or also for the host compiler?
As long as the "stddef.h" is not consistent for the target compiler on
different hosts, we at least need to report back that wchar_t has been
defined.
And the inclusion order needs to be correct, so our wchar_t gets defined
before it can be defined by "stddef.h".
But if "stddef.h" would be consistent for the target compiler on all hosts,
this problem would be gone.
Concerning the host compiler: On the one side, you wrote that tools under
Windows have to be compiled as Windows code, under Linux as Linux code, etc.
So in some cases, a tool might require a system wchar_t. And the size of
this wchar_t depends on the host.
On the other side, we always use 2-byte unsigned wchar_t's under Windows, so
our host tools probably only need this type. But this can depend on the
situation...
What host modules include target headers?
Don't understand me wrong here.
The standard C headers (like "stdio.h", "stdlib.h", etc.) are
correctly
separated between host and target (or at least, should be ;-).
What we share between both are some of the Win32 headers like "windef.h" or
"winnt.h".
An example of this is cmlib: It heavily uses Win32 types like ULONG and
UCHAR, so it has to include "winnt.h" for defining them. cmlib is shared
between host and target components, like mkhive (host) and freeldr (target).
As these headers only define other names for generic types, I see no reason
for not using them in host code as well.
Regards,
Colin