You're getting down-voted (Which is unnecessary IMO) but you're really not wrong. `gcc` itself provides `stdint.h`, it's not actually part of libc - or rather, you can use it without actually having a libc in place. Generally this is a good move, because you can always write a `stdint.h` replacement on arch's that don't have one, but on ones that do you're guaranteed to get the types correct.

I use stdint.h too, but I'm honestly curious if there is any common platform around today where one of the following asserts fails:

    int main() {

        assert(sizeof(signed char) == 1);
        assert(sizeof(short)       == 2);
        assert(sizeof(int)         == 4);
        assert(sizeof(long long)   == 8);

        return 0;
    }

I'm not interested in the language lawyering, because yes I know the standard provides more freedom to compilers. I just think those definitions are very universal for any real computer that would otherwise run my software. Please don't bring up Windows 3.1, that's about as relevant to most of us a PDP-11.

And for what it's worth, using typedefs based on the above provides more readable printf strings. This is hideous:

    int main() {

        int64_t portable = 123;
        printf("Ugly: %" PRId64 "\n", portable);
        
        return 0;
    }

Where this is acceptable:

    int main() {

        long long palatable = 123;
        printf("Better: %lld\n", palatable);
        
        return 0;
    }

Well there's a few things to keep in mind. For one, `sizeof(char)`is guarenteed to be `1` - the standard simply says so. That doesn't mean that a `char` is 8-bits long, however. On certain systems, like TI DSP's, `char` is 16-bits long, and thus `sizeof(short)` is also 1. `sizeof(int)` may be either 1 or 2, I can't recall (both are standards compliant).

All that said, POSIX requires `CHAR_BIT == 8`, which then basically ensures what you wrote to be true. So if you're willing to target POSIX (or POSIX-supporting systems) then such a thing is perfectly fine.

The `stdint.h` types are still better though, IMO, because they make your intentions a lot more clear.

I think int is 8 bytes on the PS4. (I just got bitten by this...)

How does the PS4 declare a 4 byte int? If that's "short", is there a way for a 2 byte int?

I haven't programming on the PS4, but an 8-byte `int` sound very suspect and fairly unlike (but not impossible). That said, it wouldn't be a huge issue. `short` could either be a 2-byte or 4-byte int (Either would be standards compliant), and `char` would presumably still be byte-sized (Not doing so would be a fairly big issue to deal with).

That leaves out either the 2-byte or 4-byte int from the standard data-types, but you can gain that back by simply using a compiler attribute or compiler-defined type to allow access too it. While that sounds non-standard, it really wouldn't be that bad because it could simply be used in `stdint.h` to expose the standard `int16_t` and `int32_t` types, which could be used like normal.

A lot of good programmers do that and the reason given is that types in stdint.h have ugly long names like uint32_t. "_t" thing rubs a lot of people the wrong way so I am not surprised they change it to something more pleasant. I like using uint64, int32 etc. but the convention where it's u64, i32, f32, f64 is something I would get behind.