Date: Mon, 31 Jul 2017 15:09:51 -0700 From: Mark Millard <markmi@dsl-only.net> To: Tijl Coosemans <tijl@FreeBSD.org>, toolchain@FreeBSD.org Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <719173E8-3331-4A93-9A7E-8008AD0DFC32@dsl-only.net> In-Reply-To: <2426E5EB-518A-4B5B-8866-AD11D1AB95A3@dsl-only.net> 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> <2426E5EB-518A-4B5B-8866-AD11D1AB95A3@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[I quote C++03's material about standard headers including each other: what is allowed and what is required.] On 2017-Jul-31, at 1:31 PM, Mark Millard <markmi at dsl-only.net> wrote: > On 2017-Jul-31, at 12:42 PM, Tijl Coosemans <tijl at FreeBSD.org> = wrote: >=20 >> 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. >=20 > [If you find something in the standard that I've missed in my > searches, please let me know.] >=20 > [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.] >=20 > 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. >=20 > But the standards do indicate that macro naming must avoid > conflicts with such names, including those that are private > to the implementation. >=20 > I wrote for C++03 (and before), in part quoting the standard: >=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 >=20 > And for more modern contexts (quoting C++11's wording): >=20 >> "A translation unit that include a standard library >> header shall not #define or #undef names declared >> in any standard library header." >=20 > These make it a very good idea to avoid generic macro > names that are fairly likely to be fairly common. May be > here: >=20 > #define sqobject_type(obj) ((obj)._type) >=20 > This would be far less likely to end up with conflicts > (until the standard gets something called a "sqobject" > involved anyway). >=20 >=20 > You certainly can submit a bugzilla report at: >=20 > https://bugs.llvm.org/enter_bug.cgi?product=3Dlibc%2B%2B >=20 > 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. Here is the core of what C++03 has to say about standard headers including each other. I'd not managed to quote it before. (I've been trying to avoid a "just my say so" status in what I've written.) ISO/IEC 14882:2003's 17.4 is "Library-wide requirements". 17.4.4.1 "Headers" (so: standard headers) says in part: "A C++ header may include other C++ headers." That text has a foot note 170 that says: "C++ headers must include a C++ header that contains any needed definition (3.2)." There is also a special rule for the .h form of C headers: "Header inclusion is limited as follows: -- The C headers ( .h form, described in Annex D, D.5) shall include only their corresponding C++ header, as described above (17.4.1.2)." Of course the C++ header (non-.h form) then can do more includes. Side note: It had been a long time since I'd been through this stuff --and I'd not been tracking recent C++ standard versions in much detail. It has been good for me to go through this subject area. It also has been good to see that some of the mis-matched material in earlier versions has been updated to cover things better. =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?719173E8-3331-4A93-9A7E-8008AD0DFC32>