> On Sep 6, 2017, at 5:31 PM, Andrew Trick <[email protected]> wrote: > > >> On Sep 6, 2017, at 5:17 PM, Taylor Swift <[email protected]> wrote: >> >> >> >> On Sep 6, 2017, at 7:01 PM, Andrew Trick <[email protected]> wrote: >> >>> >>>> On Sep 6, 2017, at 4:54 PM, Taylor Swift <[email protected]> wrote: >>>> >>>>> The semantics of buffer.deallocate() needs to be: free `buffer.count` >>>>> bytes of memory at `buffer.baseAddress`. So, that will always be the fast >>>>> path! >>>>> Kelvin, do you agree with that? >>>> >>>> this could be problematic if you have multiple contiguous buffers carved >>>> out of the same heap block. i agree that this is the best semantics for >>>> buffer pointers but we need the sized backend in Swift before this is >>>> possible else we will end up in the same boat we’re in right now with >>>> `deallocate(capacity:)` where we would have to make buffer deallocate heap >>>> block-based for now and then pull the rug out from underneath users later >>>> in order to switch to the improved semantics >>> >>> If I understand your proposal, it’s only valid to deallocate a buffer that >>> was allocated with the same capacity. Anything else should assert. >>> -Andy >> >> the proposal isn’t specific enough there and that’s my fault but this seems >> like a good solution. in the future if we get a sized backend we can loosen >> the assertions and make the partial heap block buffer case defined behavior. > > 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. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
