[swift-dev] Question about size of Character type

[Jordan Rose]

> On Aug 19, 2016, at 18:22, Slava Pestov <spestov at apple.com> wrote:
> 
>> 
>> On Aug 19, 2016, at 2:04 PM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160823/3e4dd5c9/attachment.html>