+    addr = other.addr;
+    len = other.len;
+    memcpy (u.buf, other.u.buf, sizeof (u.buf));
Shouldn't we check for self-assignment here ?
I don't think it would be possible to self-assign here, since this is a
move operator. We shouldn't be able to create a copy anywhere, so I
think it shouldn't be a large thing.
I can add an assert, since if it ever happens this is a large bug.
Yeah, I just noticed it since I've been looking at a sample implementation
for the move assignment operator which does check for self-assignment:

https://learn.microsoft.com/en-us/cpp/cpp/move-constructors-and-move-assignment-operators-cpp?view=msvc-170#example-complete-move-constructor-and-assignment-operator

and then compared a bit with other classes which have DISABLE_COPY_AND_ASSIGN
and the move assignment operator.

Also, like the destructor, I believe we must delete u.ptr here:
~~~
   if (len > sizeof (u.buf))
       delete[] u.ptr;
~~~

Same feedback for record_full_mem_entry &operator=
The idea of a move operation (constructor or assignment) is that we
won't need to allocate new memory, we'll just pass the pointer to the
new holder and that's it. If the pointer is deleted here, since it was
copied over in the memcpy call, when the next object calls its
destructor, we'll get a double free.
Arg, this might have been confusing.  My feedback on this is not exactly at the right line.
I'd add this delete before those lines:

+    addr = other.addr;
+    len = other.len;
+    memcpy (u.buf, other.u.buf, sizeof (u.buf));
When the object is finally destructed, I don't expect a double free, since we only free
the data of the moved object. In the move operator we delete the data of the original
object.

In the example link I shared above, also the existing data are deleted.
But it might be that I'm missing something here still.

Oh right, that makes a lot more sense, I thought the suggestion was to free the other.u.ptr lol. Sorry for the misunderstanding!

In the case of this code, I would expect that we're always assigning this to the "essentially uninitialized" variable, so again I think an assert that len == 0 is a better check. I'll run stuff locally to ensure that my understanding is correct, and if it isn't I'll add the free you suggested.

-- 
Cheers,
Guinevere Larsen
It/she