> On Nov 2, 2016, at 10:32 AM, Manfred Schubert via swift-users 
> <swift-users@swift.org> wrote:
> 
> Am 01.11.2016 um 21:43 schrieb Michael Ilseman <milse...@apple.com>:
>> 
>> This is more so a semantic distinction rather than some kind of physical 
>> operation. The memory is not altered, but all reads and writes to that 
>> memory location have to be through the “bound type”. If it’s “bound” to some 
>> type T, you must only read and write through values of type T, and not some 
>> unrelated type.
> 
> So is „binding memory to a type“ like declaring the intent to the compiler 
> that this memory is accessed as a certain type?

Yes.

>> [1] 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
> 
> Re-reading this, I guess I don’t even understand the need for memory being 
> initialized and deinitialized. I understand that it is useful to have a 
> defined initial value, but why is that a requirement for raw memory?

Memory is initialized whenever it holds a value. Memory does not need an 
“initial” value, so I’m not sure I understand the question.

API’s for reading memory do require that the memory be initialized. After all, 
they claim to return a valid value.

Deferring initialization is convenient for some contiguous data structures, but 
generally dealing with uninitialized memory is expected to be rare. About the 
only things you can do with uninitialized memory are initialize it, deallocate 
it, or copy it with C memcpy.

> If I receive raw memory from outside of Swift, would this already be „bound“ 
> and „initialized“? Many raw data can be interpreted in multiple ways, so it 
> cannot be bound to any particular type, but it is initialized with meaningful 
> data already.

If a C interface returns a pointer to uninitialized memory (e.g. malloc), then 
Swift code cannot assume that memory is bound to any type.

If a C interface returns a pointer to initialized memory, then it will be 
returning a typed pointer and indicating the capacity. Swift code can safely 
assume the memory is bound to that type.

There is a subtle issue here. I’m reluctant to bring it up because it really 
isn’t the user’s job to understand. But since we’re on the topic… It’s 
theoretically possible for a C interface to return a pointer to the same memory 
as different, unrelated, types via different functions. This is valid in C 
because of language-specific rules regarding aliasing and layout of structs, 
but would not otherwise be valid in Swift. For this reason, the compiler will 
be more conservative about aliasing of imported C types. Again, it’s not 
something the user needs to worry about.

> And what does deinitialize actually do? How could a row of Ints be 
> deinitialized for example? Or is it zeroing the raw bytes of the memory?

By definition, deinitializing a value of trivial type, such as Int, does 
absolutely nothing other than semantically “mark” the memory as deinitialized 
(it’s a nop in the implementation).

Deinitializing nontrivial values decrements reference counts, runs 
deinitializers, and what not.

-Andy

> Manfred
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to