Casey Carter 07c59eda00 Don't derive secure_allocator from std::allocator ... Affects both secure_allocator and zero_after_free_allocator. Giving the C++ Standard Committee control of the public interface of your type means they will break it. C++23 adds a new `allocate_at_least` member to `std::allocator`. Very bad things happen when, say, `std::vector` uses `allocate_at_least` from `secure_allocator`'s base to allocate memory which it then tries to free with `secure_allocator::deallocate`. Drive-by: Aggressively remove facilities unnecessary since C++11 from both allocators to keep things simple.		2023-07-24 22:33:40 -07:00
..
allocators	Don't derive secure_allocator from std::allocator	2023-07-24 22:33:40 -07:00
cleanse.cpp	scripted-diff: Bump copyright of files changed in 2019	2019-12-30 10:42:20 +13:00
cleanse.h	scripted-diff: Bump copyright headers	2022-12-24 23:49:50 +00:00
events.h	Update copyright headers to 2018	2018-07-27 07:15:02 -04:00
lockedpool.cpp	util: Remove duplicate include	2023-02-23 17:58:40 -05:00
lockedpool.h	Merge bitcoin/bitcoin#16195: util: Use void* throughout support/lockedpool.h	2023-02-23 15:44:42 -05:00