[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

Taylor Swift kelvin13ma at gmail.com
Thu Sep 7 13:57:21 CDT 2017

On Thu, Sep 7, 2017 at 1:39 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> On Sep 7, 2017, at 10:31, Andrew Trick via swift-evolution <
> swift-evolution at swift.org> wrote:
> On Sep 7, 2017, at 8:06 AM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> I don’t see any source for this claim in the documentation
> <https://developer.apple.com/documentation/swift/unsafemutablepointer/2295090-deallocate>,
> or the source code
> <https://github.com/apple/swift/blob/master/stdlib/public/core/UnsafePointer.swift.gyb#L432>.
> As far as I can tell the expected behavior is that partial deallocation
> “should” work.
> On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff <jgroff at apple.com> wrote:
>> 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.
>> -Joe
>> > “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.
>> >
>> >> 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.
>> >>
>> >> -Joe
> This discussion needs to be grounded by reiterating role of the API.
> UnsafePointer specifies the memory model without extraneous functionality
> or convenience.
> The UnsafePointer.deallocate() API *is not*:
> - a common, expected, or encouraged way to deallocate
> - the simplest, safest, or most convenient way to deallocate
> - necessarilly the most optimal path for deallocation
> I don't think this is correct. UnsafePointer.deallocate is the API you
> must use to deallocate memory allocated with UnsafePointer.allocate. *My* question
> is whether it's acceptable to break all the people who *didn't* 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 *always* need to check if the memory is
> actually in the Swift pool before even believing the 'capacity' parameter.
> (It is definitely true that the *intent* 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.)
> Jordan
> 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.
> 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.
> 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.
> -Andy
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170907/d44bfb43/attachment.html>

More information about the swift-evolution mailing list