[package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Mark Millard]

[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:
> 
>> On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard <markmi at 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=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 _<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.  
>>> 
>>> 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.
> 
> [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."
>> 
>> 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.)
> 
> 
> 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=libc%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.

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.

===
Mark Millard
markmi at dsl-only.net