[swift-evolution] [Draft] Target-specific CChar

[Dmitri Gribenko]

On Wed, Mar 2, 2016 at 9:56 AM, William Dillon via swift-evolution <
swift-evolution at swift.org> wrote:

> Please see the gist <https://gist.github.com/hpux735/eafad78108ed42879690>
> for the most up-to-date drafts.
>
> I appreciate any comments, concerns and questions!
> Improve the portability of Swift with differently signed char.
>
>    - Proposal: SE–004x
>    <https://github.com/apple/swift-evolution/blob/master/proposals/004x-target-specific-chars.md>
>    - Author: William Dillon <https://github.com/hpux735>
>    - Status: *Draft*
>    - Review manager: TBD
>
> Introduction
>
> In C, the signness of char is undefined. A convention is set by either
> the platform, such as Windows, or by the architecture ABI specification, as
> is typical on System-V derived systems. A subset of known platforms germane
> to this discussion and their char signness is provided below.
> char ARM mips PPC PPC64 i386 x86_64
> Linux/ELF unsigned 1
> <http://www.eecs.umich.edu/courses/eecs373/readings/ARM-AAPCS-EABI-v2.08.pdf> unsigned
> 2 <http://math-atlas.sourceforge.net/devel/assembly/mipsabi32.pdf> unsigned
> 3 <https://uclibc.org/docs/psABI-ppc.pdf> unsigned 4
> <http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html> signed 5
> <http://www.sco.com/developers/devspecs/abi386-4.pdf> signed 6
> <http://www.x86-64.org/documentation/abi.pdf>
> Mach-O signed [7] N/A signed [7] signed [7] signed [7] signed [7]
> Windows signed [8] signed [8] signed [8] signed [8] signed [8] signed [8]
>
> This is not a great problem in C, and indeed many aren’t even aware of the
> issue. Part of the reason for this is that C will silently cast many types
> into other similar types as necessary. Notably, even with -Wall clang
> produces no warnings while casting beteen any pair of char, unsigned char,
> signed char and int. Swift, in contrast, does not cast types without
> explicit direction from the programmer. As implemented, char is
> interpreted by swift as Int8, regardless of whether the underlying
> platform uses signed or unsigned char. As every Apple platform
> (seemingly) uses signed char as a convention, it was an appropriate
> choice. However, now that Swift is being ported to more and more platforms,
> it is important that we decide how to handle the alternate case.
>
> The problem at hand may be most simply demonstrated by a small example.
> Consider a C API where a set of functions return values as char:
>
> char charNegFunction(void)    { return  -1; }
> char charBigPosFunction(void) { return 255; }
> char charPosFunction(void)    { return   1; }
>
> Then, if the API is used in C thusly: C char negValue =
> charNegFunction(); char posValue = charPosFunction(); char bigValue =
> charBigPosFunction(); printf("From clang: Negative value: %d, positive
> value: %d, big positive value: %d\n", negValue, posValue, bigValue); You
> get exactly what you would expect on signed char platforms: From clang:
> Negative value: -1, positive value: 1, big positive value: -1 and on unsigned
> char platforms: From clang: Negative value: 255, positive value: 1, big
> positive value: 255 In its current state, swift behaves similarly to C on signed
> char platforms. From Swift: Negative value: -1, positive value: 1, big
> positive value: -1
>
> This code is available here <https://github.com/hpux735/badCharExample>,
> if you would like to play with it yourself.
> Motivation
>
> The third stated focus area for Swift 3.0 is *portability*, to quote the
> evolution document:
>
>
>    - *Portability*: Make Swift available on other platforms and ensure
>    that one can write portable Swift code that works properly on all of those
>    platforms.
>
> As it stands, Swift’s indifference to the signness of char while
> importing from C can be ignored in many cases. The consequences of
> inaction, however, leave the door open for extremely subtle and dificult to
> diagnose bugs any time a C API relies on the use of values greater than 128
> on platforms with unsigned char; in this case the current import model
> certainly violates the Principle of Least Astonishment.
>

It does violate the principle of least astonishment, but we should
acknowledge that the implementation-specific nature of C's char signedness
is making code *less* portable, not more -- because the same code can mean
different things on different platforms.  Reflecting the same in Swift
makes Swift code less portable, too.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160302/ea7b0053/attachment.html>