[swift-dev] What exactly does it mean for a Swift pointer to be initialized?

[Andrew Trick]

> On Aug 5, 2016, at 10:42 PM, Dave Abrahams via swift-dev <swift-dev at swift.org> wrote:
> 
> 
> on Fri Aug 05 2016, Andrew Trick <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/>> wrote:
> 
>>> On Aug 5, 2016, at 12:43 PM, Jens Persson <jens at bitcycle.com> wrote:
>>> 
>>> I'm trying to understand the new Swift 3 (4?) pointer API and Swift's memory model.
>>> 
>>> More specifically, I'd like to know more about what exactly it means
>> 
>>> for a pointer to be initialized or not.
>>> 
>>> For example, I suppose the following code example doesn't satisfy
>>> the precondition in the subscript documentation (ie floatsPtr not
>>> being initialized when using its subscript):
>>> 
>>> let numFloats = 123
>>> let floatsPtr = UnsafeMutablePointer<Float>.allocate(capacity: numFloats)
>>> for i in 0 ..< numFloats { floatsPtr[i] = Float(i) * 0.1 } // Setting values
>>> for i in 0 ..< numFloats { print(floatsPtr[i]) } // Getting values
>>> floatsPtr.deallocate(capacity: numFloats)
>>> 
>>> I'd like to understand why/how this could lead to undefined
>>> behavior, and what exactly it means for a pointer to be initialized
>>> or not.
>>> 
>>> I've read
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>>
>>> 
>>> But I don't feel that I fully understand what it means for a pointer
>>> to be initialized, or bound, and if the preconditions and rules for
>>> undef behavior are the same no matter if Pointee is a trivial type
>>> or a class type.
>> 
>> I think it’s common practice to initialize trivial types via subscript
>> assignment. Earlier versions of the proposal actually showed examples
>> of this and claimed that it was valid pattern. However, during review
>> those examples were removed because it encouraged bad practice and
>> complicated the issue.
>> 
>> The fact is, code like this is not going to break anything in the
>> compiler and it’s common enough that any model model verifier is going
>> to need to special-case trivial types. I think it would be fine to
>> rewrite the subscript precondition as follows:
>> 
>> /// - Precondition: the pointee at `self + i` is initialized.
>> should read
>> /// - Precondition: either the pointee at `self + i` is initialized
>> ///   or `Pointee` is a trivial type.
> 
> Depending on where you intend to make this change, you may be implicitly
> adding the requirement that every possible bit pattern is a valid
> representation of a trivial type.  It's fine if you're just changing the
> setters for pointee and subscript, but it shouldn't apply to the
> getters, IMO.

We do not want to allow reading trivial values from uninitialized memory.
I took a crack at the comments:
https://github.com/apple/swift/pull/4070 <https://github.com/apple/swift/pull/4070>

-Andy

>> 
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#trivial-types <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#trivial-types>
>> 
>> -Andy
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160806/cc7f0fd5/attachment.html>