> On Sep 9, 2017, at 8:37 AM, Andrew Trick <atr...@apple.com> wrote: > > >> On Sep 9, 2017, at 3:15 AM, Jean-Daniel <mail...@xenonium.com> wrote: >> >> >>> Le 8 sept. 2017 à 03:03, Andrew Trick via swift-evolution >>> <swift-evolution@swift.org> a écrit : >>> >>> >>>> On Sep 7, 2017, at 5:37 PM, Joe Groff <jgr...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
