From owner-freebsd-toolchain@freebsd.org Mon Jul 31 19:44:05 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77680DBC04C for ; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 44B6C65A4B for ; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 44012DBC04B; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43924DBC04A for ; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay107.isp.belgacom.be (mailrelay107.isp.belgacom.be [195.238.20.134]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9659265A4A; Mon, 31 Jul 2017 19:44:04 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3A5rpfNRZ34t5QQyPiDtWhIgH/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZr8S/bnLW6fgltlLVR4KTs6sC0LuG9fi4EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+?= =?us-ascii?q?RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPC?= =?us-ascii?q?TQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhz?= =?us-ascii?q?sGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSndbXstJWSJPAp2y?= =?us-ascii?q?YZYMAeUDM+ZXoJXyqVQVoBuiBwSgGP/jxiNUinPo26AxzuQvERvB3AwlB98Arn?= =?us-ascii?q?XUrNfxNKwPT+21y67IzS7dYPNTwzj97pPIeQ0mrPGQXLJwc87RxFIvGQPfkFqf?= =?us-ascii?q?t5HoMS6b2OgXtGib9eVgWPuphmU6pQ9xpT2vyd0tionPno8VxErE+jtnz4kuPt?= =?us-ascii?q?23VVR3Ydm+EJtfry2VKpB2Qsc7T2FvviY6zr0HtYS9fCcU1JQqwQPUZf+fc4WQ?= =?us-ascii?q?4R/vSfydLSl3iX9lYr6zmhS//Ey6xuHhVMS4zFBHpTdfnNbWrHACzRnT59CCSv?= =?us-ascii?q?t640iuxy6C1xvW6uFYOUA0krfbK4I5zr4wiJUTtUPDEzf1mErsiK+Wd0Ak9fay?= =?us-ascii?q?6+TgeLnmup6cN41wig3kLqsuncu/Af8mPQgLRWeb//+82Kfk/U3jT7VGlvw2kq?= =?us-ascii?q?/Hv5DGPckWpbO1DxVL3oss6xuzFSqq3dYckHUdMV5Ieg6Lg5DsO17UIfD4Cfm/?= =?us-ascii?q?g06rkDdu3/3GIrzhApfJLnXYnrfhZ6hy5FBHxwoo0N9T/ZVUCqsOIP7rQE/+qM?= =?us-ascii?q?TYDgMlMwyz2+voFdR91oYFVGKBGK+WLr3dvkST5u0yOeWMY5UVuDnlIfg/+/Hu?= =?us-ascii?q?lWM5mUMafaSxwZsXb3e4HvB6LEWZe3Xsg9EBHHwEvgokUuPllkaNUSVOaHqoWK?= =?us-ascii?q?I8/D47W8qaCtLmT5quyJmA2COyBJEeMmVPEFOJEF/kbIHBXPEIeWSUL9M3wRIe?= =?us-ascii?q?Ur30d44j0VmFswjhxr9uKPGcrjEZt5bL+sJ46sfouVc17zMiXJfV6H2EU2whxj?= =?us-ascii?q?BAfDQxxq0q5BUlklo=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AdBQBuh39Z/6qz9VFcGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgy9UEIEUjwCPBgGBay0BlV0OggQ?= =?us-ascii?q?khSMChAdBFwEBAQEBAQEBAQEBaiiCMyQBgkEBBTocIxALGAklDyoeBhOKM7Bdi?= =?us-ascii?q?0QBAQEBAQEBAwEBAQEBI4MoiFWEQQESAYYTBYlhiGyNIodPg0wFiHp8gXSPWpV?= =?us-ascii?q?yIQMzfwtTMQiGFIFQPjaHfoIxAQEB?= X-IPAS-Result: =?us-ascii?q?A2AdBQBuh39Z/6qz9VFcGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgy9UEIEUjwCPBgGBay0BlV0OggQkhSMChAdBFwEBA?= =?us-ascii?q?QEBAQEBAQEBaiiCMyQBgkEBBTocIxALGAklDyoeBhOKM7Bdi0QBAQEBAQEBAwE?= =?us-ascii?q?BAQEBI4MoiFWEQQESAYYTBYlhiGyNIodPg0wFiHp8gXSPWpVyIQMzfwtTMQiGF?= =?us-ascii?q?IFQPjaHfoIxAQEB?= Received: from 170.179-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.179.170]) by relay.skynet.be with ESMTP; 31 Jul 2017 21:42:52 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v6VJgpOv012592; Mon, 31 Jul 2017 21:42:52 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Mon, 31 Jul 2017 21:42:51 +0200 From: Tijl Coosemans To: Mark Millard Cc: toolchain@FreeBSD.org, Dimitry Andric Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <20170731214251.0a5de99b@kalimero.tijl.coosemans.org> In-Reply-To: References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> <20170729212706.33841c4c@kalimero.tijl.coosemans.org> <20170729230641.6cecd29d@kalimero.tijl.coosemans.org> <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:44:05 -0000 On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard wrote: > On 2017-Jul-29, at 3:24 PM, Mark Millard wrote: >> On 2017-Jul-29, at 2:06 PM, Tijl Coosemans wrote: >>> - Adding -std=c++98 still fails to compile with the same errors. >>> >>> - The compiler default is C++98: >>> % c++ -x c++ -E -dM /dev/null | grep __cplusplus >>> #define __cplusplus 199711L >>> >>> - A quick look at the libc++ headers makes it immediately obvious they >>> expose and use C++11 features in C++98 mode. >>> >>> And of course these were the very first things I checked before writing >>> my first email. >> >> Good to know. >> >> Under C++03 (and before) the basic requirements for macro names >> are different (and matching what you are attempting): 17.4.3.1.1 >> Macro Names says: >> >> "A translation unit that includes a header shall not contain any macros >> that define names declared or defined in that header." >> >> This greatly narrows the range of potential conflicts. >> >> (But my understanding is that the rule was changed in part >> because headers implicitly including content from other >> standard headers is classified as okay in the early standards >> as well and so overall the early standards were not fully >> consistent, given how macros are specified to operate.) >> >> There is the issue that even for C++03 and before: >> >> "Clauses 18 through 27 do not specify the representation of classes >> . . . An implementation may define static or non-static class members, >> or both, as needed to implement the semantics of the member functions >> specified in clauses 18 through 27." >> >> So far as I know (unlike C) C++ makes no requirements that imply >> the "extra" names involved in such must not be valid names in >> programs, although it allows for such. (Such as using __ prefixes >> or _ prefixes. Or for the global namespace: _ >> prefixes. These are reserved but not required to be used by the >> implementation from what I can tell.) So as far as I know >> such "pollution" is an implementation quality issue but not a >> standards conformance issue so long as the naming does not >> mess up programs' use of the required naming from the standard. >> >> So what you report about "type" being in use as an identifier >> in the library of itself looks greatly unfortunate to me but also >> does not seem to be a violation of the C++98, C++03, or other >> standard versions. (Drat.) >> >> I've also not found anything indicating that extra declarations >> and definitions (such as from C++11 for compiles targeting C++98 >> or C++03) would be a violation of a standard, such as C++98 or >> C++03. (At least for any addition that does not prevent programs' >> use of required aspects of the library.) >> >> This was a surprise to me. But so far I've not found anything to >> point to for a "this is wrong by the rules of the standard" >> submittal against libc++. That makes it less likely to change in >> the future. > > I should have noted two contexts that do explicitly specify that > "names reserved to the implementation" be used: > > 17.4.4.7 Derived classes says both: > > "It is unspecified whether a class in the C++ Standard Library it > itself derived from other classes (with names reserved to the > implementation)." > > "It is unspecified whether a class described in the C++ Standard > Library as derived from another class is derived from that class > directly, or through other classes (with names reserved to the > implementation) that are derived from the specified base class." > > These quotes are from ISO/EIC 14882:2003. More modern ones > that I've looked at also include a 3rd context: > > "Implementations are permitted to provide addition predefined > variables with names that are reserve to the implementation > (5.10)." > > Otherwise having extra names is not restricted to using > "names reserved to the implementation", even in C++98 > and C++03 as far as I can tell. > > (I do not have a copy of the C++98 standard with me so I'm using > C++03's instead.) You are arguing that all names are reserved to the implementation, meaning no names are available to programmers and it is impossible to write C++ code.