This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] include _mingw.h in stddef.h
On Thu, Sep 17, 2009 at 4:35 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> Ozkan Sezer wrote:
>> Hello:
>>
>> $ cat dummy.c
>> #include <stddef.h>
>> __int64 dummy;
>>
>> Without the following patch, the above example shall not compile for
>> mingw*
>
> ?I think this is a bug in your example. ?It should read:
>
> #include <_mingw.h>
> __int64 dummy;
>
This does _not_ mimic MSVC behavior. _mingw.h is a helper.
> ?Alternatively, I think there is a bug in your example. ?It should read:
>
> #include <stdint.h>
> int64_t dummy;
>
>> because certain types such as __int64 in the above example
>> (and some definitions) which are provided by the M$ compiler, are not
>> available via including gcc-provided stddef.h. ?They are, however,
>> provided by _mingw.h which is available for both mingw32 (mingw.org)
>> and mingw-w64. ?By including _mingw.h at the top of stddef.h, the
>> problem can easily be solved.
>
> ?I don't understand the problem; can you explain in more detail? ?Why should
> stddef.h be expected to define a *non*-standard type? ?There's nothing in the
> C standard that says that #includeing stddef.h will define a type called
> "__int64", so why would this be expected to work in the first place? ?If the
> real problem is support for a compiler intrinsic type, how does defining it in
> stddef.h help when people could just as well write
>
> __int64 dummy;
>
> without including any header at all? ?Would an alternative solution to be to
> add a predefine "-D__int64=int64_t" in the driver specs?
>
Add __int8, __int16, etc. to that list..
IMO, this is much more robust and transparent to users.
> ? ?cheers,
> ? ? ?DaveK
>
--
Ozkan