Eliminate uses of C types in std

[brson]

There is a lot of runtime code in std that, for various reasons, uses C types instead of Rust types. Let's push all those C types down to the FFI layer and stop using them for other purposes.

[gavinb]

Hi @brson, just to clarify the scope of this change...

Is this only to change the use of libc types in the interfaces published by modules in libstd, but to leave implementation details that use types such as c_int and c_size_t? Or should it be virtually a global replacement, with no use of libc types outside of libc itself?

What about in the external declarations of libc functions - which style should be used, as per an example in cmath?

unsafe fn acos(n: c_double) -> c_double;
unsafe fn acos(n: f64) -> f64;

IOW if we can be certain that the usage of a c_int is consistently defined on each supported arch/os, should i32 be substituted globally?

[brson]

The general guideline I suggest is that extern fns should use C types to match the C code, but Rust functions shouldn't. As one example, some of the lang items - the interface between the compiler and the library - in unstable::lang are defined in terms of C types, not Rust types.

[gavinb]

Thanks, @brson. I performed a little analysis of the libc types used in libstd and found the following:

type            frequency
c_void          306
c_int           264
c_char          126
size_t          119
c_double        113
c_float         101
FILE            55
intptr_t        48
uintptr_t       44
pid_t           10
DIR             5
ssize_t         4
dirent_t        4
c_uchar         4
mode_t          3
c_long          3
c_ulong         1

The type c_void seems to be used mainly as a generic pointer. I could either change these to *u8, or define a new generic bufptr type (in lang or sys?) to use instead.

The c_char type is frequently used for heap pointers, and should probably be replaced with *u8. Similarly, when used for strings, I think this usage should be replaced with *u8 to be consistent with the str type being a [u8]. So there's probably little call for *i8 any more, and I think existing usage of such should be changed to *u8 for consistency.

The c_double and c_float are overwhelmingly used in the extern declarations in cmath and the like, so there will be few changes there, if any.

The intptr_t and uintptr_t can be replaced with uint and int respectively. And size_t can become uint.

After having a stab at changing things piecemeal and then discovering inconsistencies lurking in every corner (eg. strings sometimes being c_char and sometimes *i8), I thought I should step back and analyse it properly first.

So, how does that sound as a plan of attack?

[pcwalton]

@gavinb Sounds good.

[bstrie]

Is our std::util::Void type a drop-in replacement for c_void?

[thestinger]

@bstrie: yeah, they're both just uninhabited enums, although neither compiles to the LLVM type that's expected for void