[PATCH] include _mingw.h in stddef.h

[Ross Ridge]

Dave Korn writes:
> I thought that a lot of what gcc and binutils do is in order to emulate
>and/or interoperate with the native tools?

With MinGW, only to a certain extent.  While binutils and Microsoft pretty
much use the same PE-COFF file format, binutils' assembly language is
completely incompatible with Microsoft's.  In practice linking Microsoft
compiled object files with the MinGW runtime library often works, but
that's mainly an accident resulting from them both using MSVCRT.DLL (or
some newer upwardly compatible DLL).  However it doesn't work in all
cases, because part of Microsoft runtime library isn't in MSVCRT.DLL.
The sort of functions you find (with different names) in libgcc.a,
don't exist in the MinGW runtime.  MinGW compiled objects won't always
interoperate with the Microsoft runtime library for the same reason.
Of course this imperfect object-level interoperability only applies
to C.  With C++ there's no compatibility at all between objects and
runtime libraries of the two different compilers, and that's very much
intentional.

As far things go at the language level there a number of things
supported in the Microsoft C/C++ compiler that GCC is unlikely to
ever implement.  Things like Microsoft compatible asm stamements, COM
attributes, __declspec(naked), non-standard template name resolution,
based pointers, SAL annotations, and all the junk for supporting managed
(.NET) code.  Features like structured exceptions and native TLS might
make it into GCC one day, but I'm not holding my breath.

Unlike the Windows version of Intel's C/C++ compiler, MinGW was never ment
to be a drop in replacement for Microsoft's C/C++ compiler.  It was
just ment to be another alternative Windows compiler, like Watcom's
or Borland's.  If Watcom's runtime library had been installed on just
about every Windows PC or if binutils had supported 32-bit OMF instead
of PE-COFF, then MinGW might have ended being more compatible with
one of these other two compilers.  The goal was to make a minimally
working compiler.  Most of the interoperability with the native tools,
which in this case are just the "dominant" tools, wasn't by design.

>> then accordlingly the only acceptable
>> patch should be one that actually implements these types in a way that's
>> compatible with MSC.
>
>  Like we do with __declspec.  I think adding the types would be a
>good thing.

Well, I'd rather if GCC didn't automatically define __declspec as a
macro, but at least with that there isn't a standard alternative that
both compilers implement.  I think a patch that implemented __int64 and
friends as macros would in practice break more code like this:

	#ifdef __GNUC__
	#define __int64 long long
	#endif
	__int64 foo;

than it would "fix".  I can't see there being much code out there that
only includes stddef.h and uses a non-standard type like __int64.

					Ross Ridge