Address char signedness differences in TestNSNumber

[hpux735]

No description provided.

[phausler]

so this applies to all distros of arm linux? IIRC Android claims signed char, but does ubuntu on arm do the same?

[tienex]

Yes, Linux/arm defaults to unsigned chars too.

[tienex]

I mean, on Ubuntu, of course.

[phausler]

it might be a bit dangerous but I wonder if we could use -funsigned-char?

[tienex]

I'm unsure that is the best strategy, @modocache tried to fix c_layout.sil in swift tests because of the same issue, he could comment if this would work. IMHO Int8 should be really signed and CChar should map to either Int8 or UInt8 depending on the underlying configuration, at the moment on Linux/arm there's no way to use a signed 8-bits data type.

[modocache]

@jckarter commented on swiftlang/swift#1103 that platform-specific checks would be preferred to using -fsigned-char.

[phausler]

hmm more the reason these should not be signed or unsigned and CChar instead (but we cannot change the type since that would constitute an API change from Foundation's perspective)

[jckarter]

We could float the idea of making CChar a distinct type on swift-evolution. We do that for other target-dependent types like CGFloat.

[hpux735]

@jckarter I'm sure @tienex and I are interested in doing that!

[tienex]

@jckarter What's interesting and a bit depressing is that at the SIL level, even CSignedChar is unsigned. I am trying to see why although, apparently, everything is correct and that should work in theory, even Clang generates signext for "signed char" correctly.

[tienex]

Oh maybe I got it wrong, is SIL still using the typealias defined in CTypes?

[jckarter]

SIL should canonicalize away all typealiases. If CSignedChar is aliased to an unsigned type, that's a bug. Do we do something dumb like typealias CSignedChar = CChar?

[tienex]

No, that's fine, CSignedChar maps to Int8 as well, like CChar, I got confused because of the BuiltinMappedTypes.def :-)

[hpux735]

@jckarter @phausler @modocache Yesterday, I submitted an email to swift-evolution to open up this discussion. https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011101.html