Date: Sat, 29 Jul 2017 15:24:44 -0700 From: Mark Millard <markmi@dsl-only.net> To: Tijl Coosemans <tijl@FreeBSD.org> Cc: Dimitry Andric <dim@FreeBSD.org>, toolchain@FreeBSD.org Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> In-Reply-To: <20170729230641.6cecd29d@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jul-29, at 2:06 PM, Tijl Coosemans <tijl at FreeBSD.org> wrote: > On Sat, 29 Jul 2017 12:43:59 -0700 Mark Millard <markmi at = dsl-only.net> wrote: >> On 2017-Jul-29, at 12:27 PM, Tijl Coosemans <tijl at FreeBSD.org> = wrote: >>>> . . . >>>=20 >>> But none of this should be exposed to C++98 code. =20 >>=20 >> Only if the compiler is told to compile the code as >> C++98 code or it is known that C++98 is the default >> target version for the compiler. >>=20 >> The compiler command that you published as part of >> the error report provides no such explicit control >> of what language/library version rules are to be >> used: >>=20 >> c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -O2 -pipe = -fstack-protector -fno-strict-aliasing -DNDEBUG -Wall -W -Wcast-qual = -Wpointer-arith -Wcast-align -DUSE_C -DREVISION=3D8163 = -I/usr/local/include/SDL -I/usr/local/include -D_REENTRANT = -D_THREAD_SAFE -DCOLOUR_DEPTH=3D16 -c -MMD -o = build/default/squirrel/squirrel/sqvm.o squirrel/squirrel/sqvm.cc >>=20 >> So if the default is to compile for C++11 or later >> the results of using the C++11 rules are the expected >> results here. >>=20 >>> These names were not >>> reserved in the C++98 standard so C++98 code is free to use them. = If >>> libc++ cannot compile such valid C++98 code it is simply not = compliant >>> with that standard. Note that in this case we were lucky to see a >>> diagnostic. C++98 code may use these names in a way that doesn't = cause >>> an error. Who's going to review our 27000 ports to make sure they = are >>> still compiled correctly? =20 >>=20 >> Unless you tell the compiler to use C++98 rules you get the >> rules of whatever version it targets by default. >>=20 >>>> For targeting -std=3Dc++11 or later in compiles >>>> __enable_if and __is_arithemtic and __type >>>> would be wrong in these places and require >>>> code using the standard to use the names >>>> that have the __ prefixes, in violation of >>>> the standard's specifications. That includes >>>> having no explicit -std=3D but depending on a >>>> default that happens to end up with c++11 or >>>> later as the version to target. =20 >>>=20 >>> Of course things like __enable_if are for internal use only. In = C++11 >>> mode enable_if needs to be made available. =20 >>=20 >> And if the compiler default version target was >> C++11 or later then what it did was what it should >> have done. >=20 > Since you've written three times the same thing here let me reply with > three times the same thing: Very true that I should not have bothered to try to write something in all 3 places. Your sequence gives additional information in each of your 3 and so does not have my mistake. > - 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. 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 _<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. 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. =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?3E4B30BB-A9E5-480E-835D-DA6797FC230C>