add intmax

[mahkoh]

Closes #17075

I don't know if this is correct. The easiest way to find out is to run the following program on all targets but I can't do it myself.

#include <stdint.h>
#include <stdio.h>

int main(void)
{
    if (sizeof(intmax_t) != 8) {
        puts("ERROR");
        return 1;
    }
}

[thestinger]

The sad thing about intmax_t is that it's incorrect. It doesn't actually correspond to the largest integer on most platforms for ABI compatibility reasons.

[nodakai]

@thestinger Could you elaborate on that? Do you perhaps have __int128_t in your mind? (There are also SIMD types such as __m128 or __vector but they are irrelevant for this discussion.)

For everyone's reference: POSIX on stdint.h:

• http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

[thestinger]

@nodakai: intmax_t is frozen as part of the platform ABI on every major OS so it does not correspond to anything meaningful. There are integer types larger than it, but it will not change in size because it would break the ABI.

[huonw]

s/i/u/

[nodakai]

@thestinger I mean, I was curious what you had in your mind as an example of "integer types larger than (intmax_t)". __int128_t is one of them but only GCC and Clang support it as an extension and I know of no C library using it in its public headers.

Though I don't think intmax_t can be essentially useful, I think it makes a sense to import as many C standard types as possible.

Wow, OpenSSL internally depends on __int128_t. Bit shift by 107 bits!

• http://codesearch.debian.net/search?q=__int128_t

[thestinger]

I think we should have it all there unconditionally and it should be generated from the C headers without any additional organization. However, the current way of doing things is that libc is only for stuff that's generally correct / useful / portable and not exposed in some other way by Rust.

[mahkoh]

It would be helpful if someone with access to the bots could check if intmax_ is i64 everywhere.

[pcwalton]

@thestinger Do you have any objections to this? I am OK with it in general but I don't have a real opinion. Just want to take action on this PR.

[thestinger]

@pcwalton: I don't think we should pick and choose the parts of libc that we expose, but we do approach it that way right now and I don't think intmax_t is actually useful. There are many useful things that are left out and pull requests adding those have been rejected in the past.

[thestinger]

If it was up to me, we would use automatic binding generation or at least pretend we were using it. That would mean exposing everything C does without organization into namespaces and not making our own decisions about which functionality is useful / portable. So under that model, this would be acceptable.

[alexcrichton]

While not explicitly spelled out, the purpose of libsys (the current liblibc) in the runtime removal RFC is to house as much of C header files as possible. Work on this has not gone much underway just yet, however.