Re: [RFC] Supporting malloc_usable_size

[DJ Delorie <dj@redhat.com>]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> On to the alternative question then; given that the interface has 
> minimal utility, unnecessarily exposes internal implementation caveats 
> and is prone to abuse, does it make sense to deprecate it?  If not, does 
> it make sense to make the note in the man page stronger by, e.g. 
> removing the "without ill effects" and discourage its use for anything 
> other than diagnostics?

I see no reason to deprecate this call, as long as it does what it's
documented to do.  Just because we think it's a bad API doesn't mean
some other developer won't find it immensely useful in some way we
haven't imagined.

Existing notes:

  The value returned by malloc_usable_size() may be greater than the
  requested size of the allocation because of alignment and minimum size
  constraints.  Although the excess bytes can be overwritten by the
  application without ill effects, this is not good programming
  practice: the number of excess bytes in an allocation depends on the
  underlying implementation.

Suggested text:?

  The value returned by malloc_usable_size() may be greater than the
  requested size of the allocation because of various internal
  implementation details, none of which the programmer should rely on.
  This function is intended to only be used for diagnostics and
  statistics; writing to the excess memory without first calling
  realloc() to resize the allocation is not supported.  The returned
  value is only valid at the time of the call; any other call to a
  malloc family API may invalidate it.

I think this is as harsh as we should go, and I'm not opposed to
removing any of the above if we think it oversteps the ABI bounds.