Lack of C99 integer types in libc


libc::types::common::c99 only contains a small subset of actual C99 integer types. Recently I was trying to interface with a C library that uses some of the other int types and it turned to be surprisingly difficult.

For the full palette of C99 int types se here: or here:

Another missing C99 type is _Bool, defined in stdbool.h

Especially the *_fast* types seem to be widely used. I’m not sure about actual merit of these ‘fast’ types, but that’s beside the point, what is important here is that people seem to be using them in library interfaces and sometimes we need to interface with those libraries.

Rust’s liblibc seems to define all the integer types by hand per architecture. Wouldn’t it perhaps be easier to write a snippet of a C code that would figure out the size of each integer? As far as I know, the build process has to use C/C++ compiler for LLVM anyway…


The original libc crate was built using a C program in the way you describe, but that script has not been maintained in a long time.

If it’s in a C standard then it probably belongs in the libc crate.


Yeah, they’re in the standard. Some of them are optional.

I realized generating the definition with a C snippet is not actually that easy, because not all compilers support C99’s types. MSVC, for example, doesn’t support C99 at all as far as I know. The code would probably need to detect this somehow…

For now I’ve put up a crate that provides these types:


@vojtechkral Support of the C library in libc is far from being complete. I have an (unfinished and a bit outdated) table of entities in the C library, extracted form the C11 standard, and and entities in Rust libc -, feel free to improve it and use it as a reference for adding the missing features in libc.


@petrochenkov Thanks. What Markdown renderer do you use? I can’t seem to get the tables rendered…


IIRC, I used sublime text markdown preview, but Github doesn’t seem to like this kind of markdown. I’ll try to do something with it.


MSVC, for example, doesn’t support C99 at all as far as I know.

That may finally be changing with VS2015. See James McNellis’ 2015-03-10T19:11 comment on this post announcing their new “Universal CRT”:

We have implemented (practically) all of the C99 Standard Library except <tgmath.h> (which requires language features not supported by the compiler).

He doesn’t explicitly mention inttypes.h, but it may be implied.


@mrec stdint.h is implemented in VS2012, inttypes.h is implemented in VS2013, and VS2015 contains a full rewrite of the C library (modulo tgmath.h requiring C11 support from compiler) with all the missing parts filled and non-conformances fixed.


@petrochenkov That’s good news! I have zero knowledge about how rustc is compiled on windows - does it use MSVC?

Also, how does Rust libc deal with features missing in the underlying libc implementation? Does it simply omit those?


@vojtechkral We actually use MinGW to build Rust on Windows. There are plans to get it working with MSVC eventually though.

Adding type definitions that the underlying libc doesn’t have don’t hurt so long as you correctly predict what the type definitions will be when the actual libc does add support for them. Functions that don’t exist will simply result in linker errors if someone attempts to use them.