diff options
| author | Tom Tromey <tromey@adacore.com> | 2024-06-05 09:51:08 -0600 |
|---|---|---|
| committer | Tom Tromey <tromey@adacore.com> | 2024-06-24 09:11:30 -0600 |
| commit | 9f71296fda412c315a8dde05b51d5163e3e2e53c (patch) | |
| tree | 3793c2a6efba6c4c9baa84d93eb217ff2d15a303 /gdbsupport/gdb-hashtab.h | |
| parent | 4122e647d571b35b4aba73ec481bc2d72d193e54 (diff) | |
| download | binutils-9f71296fda412c315a8dde05b51d5163e3e2e53c.zip binutils-9f71296fda412c315a8dde05b51d5163e3e2e53c.tar.gz binutils-9f71296fda412c315a8dde05b51d5163e3e2e53c.tar.bz2 | |
Remove hashtab_obstack_allocate
I think that hashtabs should never be obstack-allocated. In the past
this was convenient sometimes, because any new data structure needed a
corresponding cleanup. However, with the switch to C++, resource
management has become much simpler; for example, a local variable can
simply be of type htab_up rather than hashtab_t, and the problem is
solved.
This patch removes hashtab_obstack_allocate to try to prevent this
anti-pattern from being used again.
Diffstat (limited to 'gdbsupport/gdb-hashtab.h')
| -rw-r--r-- | gdbsupport/gdb-hashtab.h | 5 |
1 files changed, 0 insertions, 5 deletions
diff --git a/gdbsupport/gdb-hashtab.h b/gdbsupport/gdb-hashtab.h index 0cdcc84..05465f9 100644 --- a/gdbsupport/gdb-hashtab.h +++ b/gdbsupport/gdb-hashtab.h @@ -42,9 +42,4 @@ htab_delete_entry (void *ptr) delete (T *) ptr; } -/* Allocation and deallocation functions for the libiberty hash table - which use obstacks. */ -void *hashtab_obstack_allocate (void *data, size_t size, size_t count); -void dummy_obstack_deallocate (void *object, void *data); - #endif /* GDBSUPPORT_GDB_HASHTAB_H */ |