> On 9 Jan 2020, at 21:01, Jonathan Wakely wrote:
>
>>
>> 2020-01-09 Olivier Hainque
>>
>> libstdc++-v3/
>> * doc/xml/manual/appendix_contributing.xml: Document _C2
>> as a reserved identifier, by VxWorks.
>> * include/bits/stl_map.h: Rename _C2 template typenames as _
On 09/01/20 20:09 +0100, Olivier Hainque wrote:
Hi Jonathan,
Yes, this is fine in principle. Please update the docs and change
_Mt to _Cmp2 though.
Sure, will adjust, test and follow up.
Revised patch attached. Bootstrapped and regression tests
fine on x86_64-linux.
2020-01-09 Olivier Hai
Hi Jonathan,
>> Yes, this is fine in principle. Please update the docs and change
>> _Mt to _Cmp2 though.
>
> Sure, will adjust, test and follow up.
Revised patch attached. Bootstrapped and regression tests
fine on x86_64-linux.
2020-01-09 Olivier Hainque
libstdc++-v3/
* doc
Hello Jonathan,
> On 09 Jan 2020, at 14:26, Jonathan Wakely wrote:
>
> 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
On 09/01/20 14:00 +0100, Olivier Hainque wrote:
Hello,
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 "
Hello,
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 ex
