> On Aug 19, 2016, at 18:22, Slava Pestov <spes...@apple.com> wrote:
>
>>
>> On Aug 19, 2016, at 2:04 PM, Jordan Rose via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>> We have an old Radar about this, rdar://problem/16754935
>> <rdar://problem/16754935>. It's probably just a case we're missing in enum
>> layout. My guess is that it's because we don't have a whole spare bit in a
>> RawPointer, but we should be able to pick some up either from alignment or
>> from ABI knowledge.
>>
>> Jordan
>
> Hi Jordan,
>
> I asked about a related issue, which is that RawPointer only has 1 extra
> inhabitant instead of 4096. You guys said you wanted non-zero integers to
> round-trip through RawPointer. It seems that declaring the high bits of a
> RawPointer as spare bits would cause the same problem as allowing more extra
> inhabitants.
>
> Also I don’t think alignment is the answer here, RawPointer should be able to
> represent a char *, where you have no low spare bits.
Ah, yeah, sorry, I didn't really mean RawPointer here. I do think
Builtin.RawPointer should continue to be able to round-trip with Int (except 0)
because of the things people do in C. I should have said "known non-tagged
object pointer", which has to be a valid address, and which
_StringBuffer._Storage certainly should be.
I dug into this a little, and it looks like we've got this nesting:
case large(_StringBuffer._Storage)
typealias _StringBuffer._Storage = _HeapBuffer<_StringBufferIVars,
UTF16.CodeUnit>
struct _HeapBuffer<Value, Element> {
internal var _storage: Builtin.NativeObject?
}
So because _HeapBuffer can be empty, we get into trouble. We don't have a
_NonEmptyHeapBuffer, but I suppose we could store a
_StringBuffer._Storage.Storage instead.
Jordan
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
