OK, I filed [SR-466] as a compiler issue. If the behaviour changes and that 
flows through to Darwin Foundation, we can update the open source one...

— Luke

> On 5 Jan 2016, at 8:21 AM, Philippe Hausler <phaus...@apple.com> wrote:
> 
> No C strings import as UnsafePointer<CChar> for some reason; they all import 
> as Int8
> 
> e.g.
> public func pthread_setname_np(_: UnsafePointer<Int8>) -> Int32
> 
> 
>> On Jan 4, 2016, at 1:20 PM, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi Luke,
>> 
>>> On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Many Foundation APIs use Int8 instead of CChar when representing C strings, 
>>> e.g.:
>>> var UTF8String: UnsafePointer 
>>> <https://developer.apple.com/library/mac/documentation/Swift/Reference/Swift_UnsafePointer_Structure/index.html#//apple_ref/swift/struct/s:VSs13UnsafePointer><Int8
>>>  
>>> <https://developer.apple.com/library/mac/documentation/Swift/Reference/Swift_Int8_Structure/index.html#//apple_ref/swift/struct/s:VSs4Int8>>
>>>  { get }
>>> I don’t know if/when Swift will be ported to a platform where the character 
>>> type is unsigned but perhaps it would be good to update these to take CChar 
>>> instead?
>>> 
>>> — Luke
>>> 
>> 
>> I’m not really sure why it’s imported to Swift as an unsafe pointer to Int8 
>> anyway. The Objective-C code uses char:
>> 
>> @property (nullable, readonly) __strong const char *UTF8String 
>> NS_RETURNS_INNER_POINTER;     // Convenience to return null-terminated UTF8 
>> representation
>> 
>> - (nullable instancetype)initWithUTF8String:(const char 
>> *)nullTerminatedCString;
>> 
>> - Tony
>> 
>> 
>> _______________________________________________
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

--
www.lukehoward.com
soundcloud.com/lukehoward

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

Reply via email to