From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 19 10:30:02 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E41E9E; Wed, 19 Mar 2014 10:30:02 +0000 (UTC) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id DBC6D1A5; Wed, 19 Mar 2014 10:30:01 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUGAFVwKVNR8YKK/2dsb2JhbABagwaBBsJjgRkXdIIlAQEBBCcTHCMQCw4KCSUPKh4GExuHYgHPKheNeWwHhDgBA5hGilqHV4MuPIE1 Received: from 138.130-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.130.138]) by relay.skynet.be with ESMTP; 19 Mar 2014 11:29:52 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s2JATqG8002518; Wed, 19 Mar 2014 11:29:52 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Wed, 19 Mar 2014 11:29:52 +0100 From: Tijl Coosemans To: Dimitry Andric 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: References: <20140318163834.6a9cf12b@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 10:30:02 -0000 On Tue, 18 Mar 2014 18:47:18 +0100 Dimitry Andric wrote: > On 18 Mar 2014, at 16:38, Tijl Coosemans 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 >> % 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.