Simon Marchi 8b8f98ad2b gdbsupport/intrusive-list: add owning_intrusive_list ... It occured to me that `intrusive_list<solib>`, as returned by `solib_ops::current_sos`, for instance, is not very safe. The current_sos method returns the ownership of the solib objects (heap-allocated) to its caller, but the `intrusive_list<solib>` type does not convey it. If a function is building an `intrusive_list<solib>` and something throws, the solibs won't automatically be deleted. Introduce owning_intrusive_list to fill this gap. Interface --------- The interface of owning_intrusive_list is mostly equivalent to intrusive_list, with the following differences: - When destroyed, owning_intrusive_list deletes all element objects. The clear method does so as well. - The erase method destroys the removed object. - The push_front, push_back and insert methods accept a `unique_ptr<T>` (compared to `T &` for intrusive_list), taking ownership of the object. - owning_intrusive_list has emplace_front, emplace_back and emplace methods, allowing to allocate and construct an object directly in the list. This is really just a shorthand over std::make_unique and insert (or push_back / push_front if you don't care about the return value), but I think it is nicer to read: list.emplace (pos, "hello", 2); rather than list.insert (pos, std::make_unique<Foo> ("hello", 2)); These methods are not `noexcept`, since the allocation or the constructor could throw. - owning_intrusive_list has a release method, allowing to remove an element without destroying it. The release method returns a pair-like struct with an iterator to the next element in the list (like the erase method) and a unique pointer transferring the ownership of the released element to the caller. - owning_intrusive_list does not have a clear_and_dispose method, since that is typically used to manually free items. Implementation -------------- owning_intrusive_list privately inherits from intrusive_list, in order to re-use the linked list machinery. It adds ownership semantics around it. Testing ------- Because of the subtle differences in the behavior in behavior and what we want to test for each type of intrusive list, I didn't see how to share the tests for the two implementations. I chose to copy the intrusive_list tests and adjust them for owning_intrusive_list. The verify_items function was made common though, and it tries to dereference the items in the list, to make sure they have not been deleted by mistake (which would be caught by Valgrind / ASan). Change-Id: Idbde09c1417b79992a0a9534d6907433e706f760 Co-Authored-By: Pedro Alves <pedro@palves.net> Reviewed-by: Keith Seitz <keiths@redhat.com>		2024-09-13 07:38:56 -04:00
..
array-view-selftests.c
child-path-selftests.c
cli-utils-selftests.c
command-def-selftests.c
common-utils-selftests.c
copy_bitwise-selftests.c
enum-flags-selftests.c
environ-selftests.c
filtered_iterator-selftests.c
format_pieces-selftests.c
frame_info_ptr-selftests.c
function-view-selftests.c
gdb_tilde_expand-selftests.c
gmp-utils-selftests.c
intrusive_list-selftests.c
lookup_name_info-selftests.c
main-thread-selftests.c
memory-map-selftests.c
memrange-selftests.c
mkdir-recursive-selftests.c
observable-selftests.c
offset-type-selftests.c
packed-selftests.c
parallel-for-selftests.c
parse-connection-spec-selftests.c
path-join-selftests.c
ptid-selftests.c
rsp-low-selftests.c
scoped_fd-selftests.c
scoped_ignore_signal-selftests.c
scoped_mmap-selftests.c
scoped_restore-selftests.c
search-memory-selftests.c
style-selftests.c
tracepoint-selftests.c
tui-selftests.c
ui-file-selftests.c
unique_xmalloc_ptr_char.c
unpack-selftests.c
utils-selftests.c
vec-utils-selftests.c
xml-utils-selftests.c