<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 11:57 AM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Sep 7, 2017 at 1:39 PM, Jordan Rose <span dir="ltr" class=""><<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 10:31, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_1247544992164468227Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 8:06 AM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_1247544992164468227Apple-interchange-newline"><div class=""><div dir="ltr" class="">I don’t see any source for this claim in the <a href="https://developer.apple.com/documentation/swift/unsafemutablepointer/2295090-deallocate" target="_blank" class="">documentation</a>, or the <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/UnsafePointer.swift.gyb#L432" target="_blank" class="">source code</a>. As far as I can tell the expected behavior is that partial deallocation “should” work.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff <span dir="ltr" class=""><<a href="mailto:jgroff@apple.com" target="_blank" class="">jgroff@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_1247544992164468227HOEnZb"><div class="m_1247544992164468227h5">
<br class="">
</div></div>The segfaulting example is an incorrect usage. The only valid parameters to deallocate(capacity:) are the base address of an allocation, and the original capacity passed into allocate(); it has never been intended to support partial deallocation of allocated blocks. It seems to me like this proposal is based on a misunderstanding of how the API works. The documentation and/or name should be clarified.<br class="">
<span class="m_1247544992164468227HOEnZb"><font color="#888888" class=""><br class="">
-Joe<br class="">
</font></span><div class="m_1247544992164468227HOEnZb"><div class="m_1247544992164468227h5"><br class="">
> “fixing” this bug will cause programs that once operated on previously valid assumptions of “free()” semantics to behave differently, without any warnings ever being generated. Conversely incorrect code will suddenly become “correct” though this is less of a problem.<br class="">
><br class="">
>> A sized implementation may fail more obviously when you violate the contract in the future. Not having sized deallocation is a known deficiency of the C model we've been fairly diligent about avoiding in Swift's allocation interfaces, and it would be extremely unfortunate for us to backpedal from it.<br class="">
>><br class="">
>> -Joe<br class=""></div></div></blockquote></div></div></div></blockquote><br class=""></div><div class=""><div class="">This discussion needs to be grounded by reiterating role of the API. UnsafePointer specifies the memory model without extraneous functionality or convenience.</div><div class=""><br class=""></div><div class="">The UnsafePointer.deallocate() API *is not*:</div><div class=""><br class=""></div><div class="">- a common, expected, or encouraged way to deallocate</div><div class=""><br class=""></div><div class="">- the simplest, safest, or most convenient way to deallocate</div><div class=""><br class=""></div><div class="">- necessarilly the most optimal path for deallocation</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I don't think this is correct. UnsafePointer.deallocate is the API you must use to deallocate memory allocated with UnsafePointer.allocate. <i class="">My</i> question is whether it's acceptable to break all the people who <i class="">didn't</i> know this and are using it to deallocate memory allocated with malloc or new on Apple platforms. It sounds like the answer to that is "no, we want to be malloc-compatible", and therefore the 'capacity' parameter isn't currently serving a purpose today. We will <i class="">always</i> need to check if the memory is actually in the Swift pool before even believing the 'capacity' parameter.</div><div class=""><br class=""></div><div class="">(It is definitely true that the <i class="">intent</i> was for this to be the allocation capacity, and I'm surprised you interpreted it as supporting partial deallocation. But we probably can't fix that at this point.)</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Jordan</div><br class=""></font></span><blockquote type="cite" class=""><div class=""><span class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">There is only one decision that needs to be made here. Does the Swift runtime track allocation size for manually allocated blocks? I think the answer should be "yes", or at least haven't heard a strong argument against it. UnsafePointer.deallocate() needs to direcly reflect that model by making `allocatedCapacity` an *optional* argument.</div><div class=""><br class=""></div><div class="">Discussion about whether this API is unsafe, misleading, suboptimal or incorrectly implemented are secondary. Those are all deficiencies in the current documentation, current implementation, and availability of higher-level APIs.</div><div class=""><br class=""></div><div class="">Note that yesterday I argued that an optional argument wasn't worth the potential for confusion. That's true from a practical perspective, but I had lost sight of need to clearly specify the memory model. We want the Swift runtime to both have the functionality for tracking block size and also allow user code to track it more efficiently. Both those intentions need to be reflected in this API.</div><div class=""><br class=""></div></div><div class="">-Andy</div></div></span><span class="">______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></span></div></blockquote></div><br class=""></div></blockquote><div class=""><br class=""></div><div class="">I mean I would have thought it’s reasonable to expect that if the method asks for a capacity parameter, it will actually use it </div></div></div></div></div></blockquote><br class=""></div><div>It will.</div><div><br class=""></div><div>-Joe</div></body></html>