[swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Andrew Trick]

> On Sep 9, 2017, at 8:37 AM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Sep 9, 2017, at 3:15 AM, Jean-Daniel <mailing at xenonium.com> wrote:
>> 
>> 
>>> Le 8 sept. 2017 à 03:03, Andrew Trick via swift-evolution <swift-evolution at swift.org> a écrit :
>>> 
>>> 
>>>> On Sep 7, 2017, at 5:37 PM, Joe Groff <jgroff at apple.com> wrote:
>>>>> 
>>>>> The important thing is that the UnsafeBufferPointer API is clearly documented. We do not want users to think it’s ok to deallocate a smaller buffer than they allocated.
>>>>> 
>>>>> Unfortunately, there’s actually no way to assert this in the runtime because malloc_size could be larger than the allocated capacity. Incorrect code could happen to work and we can live with that.
>>>> 
>>>> Would it be sufficient to assert that malloc_good_size(passedCapacity) == malloc_size(base) ? It wouldn't be perfect but could still catch a lot of misuses.
>>> 
>>> That theory does hold up for a million random values, but I don’t know if we can rely on malloc_size never being larger than roundUp(sz, 16). Greg?
>> 
>> You can’t. This may be true while alloc size if less than a page, but a quick test show that:
>> 
>> malloc_size(malloc(4097)) = 4608
> 
> Thanks, I was being a bit silly...
> We also have malloc_good_size(4097) = 4608.
> 
> What I was getting at is, can malloc_good_size be “dumb” for any legal implementation of malloc zones?
> 
> Or can we assert malloc_good_size(x) == malloc_size(malloc(x)?
> 
> -Andy

Answer:
- this assumption is obviously dependent on a particular implementation of libc.
- users implement their malloc zone however they like (although Swift doesn't strictly *need* to be compatible with them).
- even current implementations of libc have various operating modes that could violate the assertion, you would need to guard the check
  with a runtime condition.

-Andy