Date: Mon, 31 Jul 2017 13:31:56 -0700 From: Mark Millard <markmi@dsl-only.net> To: Tijl Coosemans <tijl@FreeBSD.org> Cc: toolchain@FreeBSD.org, Dimitry Andric <dim@FreeBSD.org> Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <2426E5EB-518A-4B5B-8866-AD11D1AB95A3@dsl-only.net> In-Reply-To: <20170731214251.0a5de99b@kalimero.tijl.coosemans.org> References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <F47E0976-759A-45A0-8421-8FD4402A9980@FreeBSD.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> <D780E949-FB27-4A84-8E10-75D1E7A8EA06@dsl-only.net> <20170729212706.33841c4c@kalimero.tijl.coosemans.org> <D4345C7E-29E1-42CC-B970-82EF6439237A@dsl-only.net> <20170729230641.6cecd29d@kalimero.tijl.coosemans.org> <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> <C6F2D60F-5FEC-4858-99B8-E3B04EB467A6@dsl-only.net> <20170731214251.0a5de99b@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jul-31, at 12:42 PM, Tijl Coosemans <tijl@FreeBSD.org> wrote: > On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard <markmi@dsl-only.net> = wrote: >> On 2017-Jul-29, at 3:24 PM, Mark Millard <markmi at dsl-only.net> = wrote: >>> On 2017-Jul-29, at 2:06 PM, Tijl Coosemans <tijl at FreeBSD.org> = wrote: >>>> - Adding -std=3Dc++98 still fails to compile with the same errors. >>>>=20 >>>> - The compiler default is C++98: >>>> % c++ -x c++ -E -dM /dev/null | grep __cplusplus >>>> #define __cplusplus 199711L >>>>=20 >>>> - A quick look at the libc++ headers makes it immediately obvious = they >>>> expose and use C++11 features in C++98 mode. >>>>=20 >>>> And of course these were the very first things I checked before = writing >>>> my first email. =20 >>>=20 >>> Good to know. >>>=20 >>> 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: >>>=20 >>> "A translation unit that includes a header shall not contain any = macros >>> that define names declared or defined in that header." >>>=20 >>> This greatly narrows the range of potential conflicts. >>>=20 >>> (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.) >>>=20 >>> There is the issue that even for C++03 and before: >>>=20 >>> "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." >>>=20 >>> 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 _<upper-case-letter> 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. >>>=20 >>> 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.) >>>=20 >>> 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.) >>>=20 >>> 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. =20 >>=20 >> I should have noted two contexts that do explicitly specify that >> "names reserved to the implementation" be used: >>=20 >> 17.4.4.7 Derived classes says both: >>=20 >> "It is unspecified whether a class in the C++ Standard Library it >> itself derived from other classes (with names reserved to the >> implementation)." >>=20 >> "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." >>=20 >> These quotes are from ISO/EIC 14882:2003. More modern ones >> that I've looked at also include a 3rd context: >>=20 >> "Implementations are permitted to provide addition predefined >> variables with names that are reserve to the implementation >> (5.10)." >>=20 >> 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. >>=20 >> (I do not have a copy of the C++98 standard with me so I'm using >> C++03's instead.) >=20 > 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. [If you find something in the standard that I've missed in my searches, please let me know.] [It is possible to write some C++ code without defining any macros. Macros are a bigger issue because they do not have/respect scope rules that limit where conflicts can occur.] No. Names local to classes (for example) that are from the standard library implementation do not constraint non-macro names used outside those scopes (for example). To my surprise those names are not required to be from the reserved naming space. But the standards do indicate that macro naming must avoid conflicts with such names, including those that are private to the implementation. I wrote for C++03 (and before), in part quoting the standard: > "A translation unit that includes a header shall not contain any = macros > that define names declared or defined in that header." >=20 > This greatly narrows the range of potential conflicts. >=20 > (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.) And for more modern contexts (quoting C++11's wording): > "A translation unit that include a standard library > header shall not #define or #undef names declared > in any standard library header." These make it a very good idea to avoid generic macro names that are fairly likely to be fairly common. May be here: #define sqobject_type(obj) ((obj)._type) This would be far less likely to end up with conflicts (until the standard gets something called a "sqobject" involved anyway). You certainly can submit a bugzilla report at: https://bugs.llvm.org/enter_bug.cgi?product=3Dlibc%2B%2B since FreeBSD gets libc++ from there (upstream). Complaints about quality issues that do not mean non-conformance are a valid thing to report so even if they agree with me on that point the submittal would be valid. llvm folks are just less likely to act on such issues. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2426E5EB-518A-4B5B-8866-AD11D1AB95A3>