__builtin_dynamic_object_size and snmalloc

On twitter @richfelker has said we should consider providing __builtin_dynamic_object_size as a more comprehensive way to provide guarded memcpy like features:

I'd love if there were some clean agreed upon way to get the size as a stronger version of __builtin_dynamic_object_size so this would be usable in all the FORTIFYable interfaces not just memcpy.
twitter

and

The right way to do this is the way fortify works. Not putting linkage to malloc in the external memcpy, but providing an enhanced __builtin_dynamic_object_size that can query the allocator for knowledge of size.
twitter

I'm raising this issue to build a discussion of what this should mean with snmalloc.

The Clang documentation is here:
https://clang.llvm.org/docs/LanguageExtensions.html#evaluating-object-size-dynamically

Here is the LLVM review adding it
https://reviews.llvm.org/D56760

It doesn't seem it works from an offset into an object. But I think this is worth experimenting with, as it would allow the compiler to remove some checks, and then what is left to be passed to the snmalloc routine.

I think we could define __builtin_dynamic_object_size as just remaining_bytes from snmalloc.

@davidchisnall thoughts? Is there something sensible that could be experimented with here?

Start with the linked Clang documentation on evaluating object size dynamically and the LLVM review D56760. Then review snmalloc's guarded memcpy documentation and the discussion about using remaining_bytes. Done would require an agreed meaning for __builtin_dynamic_object_size in snmalloc and an experiment showing how it interacts with the allocator routine.