On Mon, 3 Aug 2020 at 11:10, Thomas Munro <thomas.mu...@gmail.com> wrote: > I think you can probably go further, though, and make it require no > storage at all by making it optionally "intrusive", by using a special > value in an existing member, and supplying an expression to set and > test for that value. For example, maybe some users have a pointer but > never want to use NULL, and maybe some users already have a field > holding various flags that are one bit wide and can spare a bit.
I agree that it would be good to allow users of simplehash.h that additional flexibility. It may allow additional memory savings. However, it would mean we'd need to do some additional work when we create and grow the hash table to ensure that we mark new buckets as empty. For now, we get that for free with the zeroing of the newly allocated memory, but we couldn't rely on that if we allowed users to define their own macro. It looks like none of the current callers could gain from this 1. TupleHashEntryData does not have any reusable fields. The status should fit in the padding on a 64-bit machine anyway. 2. PagetableEntry already has a status that fits into the padding. 3. manifest_file could have its status moved to the end of the struct and made into a char and the struct would be the same size as if the field did not exist. So, with the current users, we'd stand to lose more than we'd gain from doing it that way. David
