Date: Wed, 19 Mar 2014 11:29:52 +0100 From: Tijl Coosemans <tijl@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: toolchain@FreeBSD.org Subject: Re: clang 3.4 -fms-extensions __wchar_t conflicts with our __wchar_t Message-ID: <20140319112952.1384ec64@kalimero.tijl.coosemans.org> In-Reply-To: <B1B0DC6C-F78B-4DCD-A073-240355CC41E4@FreeBSD.org> References: <20140318163834.6a9cf12b@kalimero.tijl.coosemans.org> <B1B0DC6C-F78B-4DCD-A073-240355CC41E4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Mar 2014 18:47:18 +0100 Dimitry Andric wrote:
> On 18 Mar 2014, at 16:38, Tijl Coosemans <tijl@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140319112952.1384ec64>