[swift-users] What is "binding" memory?

[Jordan Rose]

> On Nov 2, 2016, at 15:50, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
> 
> 
> on Wed Nov 02 2016, Andrew Trick <atrick-AT-apple.com <http://atrick-at-apple.com/>> wrote:
> 
>>> On Nov 2, 2016, at 12:58 PM, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
>>> 
>>>> At the top of the migration guide is a link to the memory model explanation:
>>>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
>>>> 
>> 
>>>> "A memory location's bound type is an abstract, dynamic property of the memory used to formalize
>>>> type safety.”
>>>> 
>>>> I’m not sure I like the “prepares the memory” language myself. Binding
>>>> memory communicates to the compiler that the memory locations are safe
>>>> for typed access. Nothing happens at runtime--until someone writes a
>>>> type safety sanitizer. 
>>> 
>>> Well, that's a slight overstatement IMO.  Sanitizers aside, the main
>>> reason for these binding operations is that if you leave them out,
>>> something different *will* happen at runtime... something that will make
>>> your code do the wrong thing.
>>> 
>>> What I would say is that binding the memory has no immediate runtime
>>> cost... but it's absolutely required if you want your program to behave
>>> (and sometimes behaving correctly is a little slower than misbehaving).
>> 
>> Good clarification. I really did not mean to imply that binding memory
>> to a type has no effect on runtime behavior. Taken out of context,
>> “nothing happens at runtime” is quite an understatement.
>> 
>> The original poster seemed to have the impression that the operation
>> of binding memory itself might affect program state, 
> 
> Formally speaking, it does!
> 
>> independent of any compiler optimization. I want to make it clear that
>> a call to bindMemory(to:capacity:) has no observable runtime side
>> effects at the point of the call. 
> 
> Only because you can't observe what memory is bound to.
> 
>> But I need to throw in an exemption for future sanitizers.
> 
> I don't think you do; sanitizer actions are allowed under undefined
> behavior.

I think the difference here is that sanitizers affect program characteristics even for correct programs. Introducing a sanitizer can reduce optimization opportunities, changing an algorithm’s complexity. And of course, there’s always a bit of bookkeeping code being executed that wouldn’t be there otherwise.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161102/5ef96cbd/attachment.html>