Invalid macro names in tests

[François Dumont]

Hi

I don't know if you will come to the same conclusion but I think 
alloc_ptr_ignored.cc test cannot PASS, at best it could XFAIL.

Unless when _GLIBCXX_USE_ALLOC_PTR_FOR_XXX is 0 you simply want to 
ignore the _Alloc template parameter entirely and fallback on 
std::allocator ?

Otherwise you have problems with node_handle definition or with the 
result of CustomPointerAlloc::allocate that cannot be converted to a _Node*.


On 11/12/2024 14:03, Jonathan Wakely wrote:
> On Wed, 11 Dec 2024 at 07:42, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>
>>
>> On Wed, 11 Dec 2024, 06:01 François Dumont, <frs.dumont@gmail.com> wrote:
>>> Hi
>>>
>>> Working on adapting the same tests for _Rb_tree I noticed that the
>>> macros used in new alloc_ptr_ignored.cc tests are not the ones you
>>> eventually chose Jonathan.
>>>
>>> I could have commit this trivial fix myself but the std::list test is
>>> then failing so I think it is better that I leave it to you.
>>
>> Thanks, I'll fix this at the same time as the incorrect noexcepts you pointed out in std::list.
>
> Actually, it seems impossible to implement std::list if
> std::pointer_traits::pointer_to can throw, because we need the
> std::list default constructor to be noexcept, but we need to be able
> to form a _Base_ptr to the sentinel node nested within the std::list
> itself (which was never allocated, so we have to use pointer_to). It
> seems that the standard is missing some guarantees that make it
> possible to safely use fancy pointers in containers. I'm going to just
> assume that pointer_to never throws and make the member functions of
> _Node_base noexcept, because we don't have any other choice.
>
I'll adapt my PR the same then.

François