clang 3.4 -fms-extensions __wchar_t conflicts with our __wchar_t

[Tijl Coosemans]

On Tue, 18 Mar 2014 18:47:18 +0100 Dimitry Andric wrote:
> On 18 Mar 2014, at 16:38, Tijl Coosemans <tijl at freebsd.org> wrote:
>> With -fms-extensions clang 3.4 seems to define a built-in type named
>> __wchar_t.  This conflicts with __wchar_t in /usr/include/machine/_types.h
>> 
>> 
>> % cat test.c 
>> #include <sys/types.h>
>> % cc -c test.c -fms-extensions
>> In file included from test.c:1:
>> In file included from /usr/include/sys/types.h:44:
>> In file included from /usr/include/machine/endian.h:6:
>> In file included from /usr/include/x86/endian.h:37:
>> In file included from /usr/include/sys/_types.h:33:
>> In file included from /usr/include/machine/_types.h:6:
>> /usr/include/x86/_types.h:145:14: error: cannot combine with previous 'int'
>>      declaration specifier
>> typedef int             __wchar_t;
>>                        ^
>> 1 error generated.
>> 
>> 
>> What is the best way to resolve this?  Maybe rename the FreeBSD __wchar_t
>> to ___wchar_t?
> 
> Maybe just don't use -fms-extensions, at least not in combination with
> our system headers?  It is not needed for the base system anymore, see
> r260020, r260102 and r260322.  E.g. clang does not need -fms-extensions
> to stop complaining about anonymous unions, like gcc.
> 
> Otherwise, the only solution is indeed to rename our __wchar_t.  The
> following type names are reserved in Microsoft mode:
> 
> __int8
> __int16
> __int32
> __wchar_t

I have a port that uses -fms-extensions for something like this:

struct a {
	int aa;
};
struct b {
	struct a;
	int bb;
};
void
test( struct b *arg ) {
	arg->aa = 1; /* clang errors on this without -fms-extensions */
	arg->bb = 2;
}

Maybe it's a bug (inconsistency) in clang that it accepts the definition
of struct b but it doesn't accept accessing the aa field?  It cannot be
accessed in any other way than in the example above.

Anyway, -fms-extensions should work too so I think I'll go ahead and
rename __wchar_t.