[PATCH 5/5] include: Fix conflicting definitions of NULL, wchar_t, wint_t, wctype_t.

[Jacek Caban]

On 22.07.2020 16:19, Puetz Kevin A wrote:
>>> But I don't think this actually makes a lot of sense either. Windows
>>> SDK 10.0.17763.0 drags in windef.h -> minwindef.h -> winnt.h ->
>>> ctype.h -> corecrt.h, and also  winnt.h -> guiddef.h -> string.h. By
>>> the end you're only avoiding __threadid(), __threadhandle(),
>>> offsetof(), and (for c++) std::nullptr_t, the rest of corecrt.h gets pulled in
>> eventually anyway.
>>
>> Oh, good catch, I didn't notice that. Then maybe we could could move
>> existing NULL define after #include <winnt.h> and guard with #ifndef NULL
>> (instead of #undefing)?
> `winecpp -fdirectives-only` is a nice way to look at how all the inclusion plays out
>
> That would leave NULL undefined for the first portion of <winnt.h>
> (and thus during <basetsd.h, guiddef.h, winapifamily.h).
> It doesn't look like that would actually break anything currently,
> (I see no inlines or anything in those headers that use NULL)
> but differs from the Windows SDK and feels weird.
>
> My thought was that, since the extra symbols will eventually get defined anyway,
> that even less risk if the libc doesn’t do __need_* and we get them early,
> so we can just use <stddef.h> right away (thus clearly and portably follow ODR).
> Even if __need_* doesn’t work as intended, we just get things early that we
> were eventually going to get anyway.


Sure, sounds reasonable, but if we're going to going to include entire 
stddef.h anyway, there is no need for using __need_* macros. It's not a 
big deal and we will still makes sense to use it in basetyps.h, but it's 
always nice to simplify things (eg. someone reading the header will not 
have to research what __need_NULL macro does). We can include stddef.h 
earlier in windef.h if you think that reordering may be problematic.


Thanks,

Jacek