[patch] rename local _C2 identifiers in stl map header files
Thu Jan 9 13:33:00 GMT 2020
On 09/01/20 14:00 +0100, Olivier Hainque wrote:
>The attached patch is a proposal to simply rename a template
>type name in stl_map.h and stl_multimap.h in order to prevent
>clashes with a macro name exposed by a system header on VxWorks.
>The conflicting name is _C2, which in principle is "reserved"
>for the system so having such a macro exposed by a system header
>doesn't seem to be a bug per se.
>I suppose that the libstdc++ headers can be considered part of
>the system as well in a way, so it's not really a bug there either.
Any conflict with OS headers is treated as a libstdc++ bug. We don't
own the entire implementation namespace, so we have to play nice and
avoid OS names.
We maintain a list of identifiers to avoid, but _C2 is currently
missing. Could you please add it to the coding_style.bad_identifiers
section in doc/xml/manual/appendix_contributing.xml so we know not to
reintroduce _C2 in future? Thanks.
>Fixing the OS headers is a major hassle on VxWorks, however,
>especially with more recent versions of the system, so we arranged
>not to rely on it at all up to now and a straightforward adjustment
>in the libstdc++ headers offers a way smoother and simpler way
>I'm not sure what "C2" was intended to refer to so I picked
It's the Comparison function for the container. Please use _Cmp2,
which is consistent with the partial specialization defined at the end
of the <bits/stl_map.h> header.
>an alternate name which seemed to match some aspects of the context
>while keeping the very-short-identifier style used throughout.
>This cures a lot of test failures with our gcc-9 based
>toolchains for VwWorks 7 and applies cleanly on mainline.
>I'm running a bootstrap & regression test cycle on x86_64-linux
>Would this be OK to commit ?
Yes, this is fine in principle. Please update the docs and change
_Mt to _Cmp2 though.
More information about the Libstdc++