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

[Dave Abrahams]

on Wed Nov 02 2016, Andrew Trick <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.

-- 
-Dave