Use a few integer types from the compiler

[yamt]

Summary

The main motivaion is to allow to use -Wformat compiler warnings.
Otherwise, it complains on long vs long long differences for intmax_t.

Note: The compiler only knows the printf format and the host OS types.
It doesn't know NuttX types.

Note: On both of 64-bit macOS and Ubuntu x86_64, the host intmax_t
is "long int" while NuttX's intmax_t without this change is
"signed long long". While they are both 64-bit integers, clang -Wformat
complains on the difference.

Impact

all archs, especially 64-bit ones

Testing

tested with local app on sim/macOS

[yamt]

finally the ci is green. yay.

[xiaoxiang781216]

@yamt great work! but there are many intermediate patches, can you organize the patch series into two:

1. Fix type mismatch and nxstyle(or better to has nxstyle fix in a standalone patch)
2. inttype.h correction and printflike annotation(or better to split the annotation into another patch)

The fix for type, nxstyle and annotation is good and ready to merge, inttype.h need more review and dissuss.

[yamt]

i guess compilers used for arch/z80 and arch/z16 don't provide __INTMAX_TYPE__ or __UINTMAX_TYPE__.
@patacongo is it right?

in that case, those types.h need to be updated to provide _intmax_t and _uintmax_t.

[patacongo]

i guess compilers used for arch/z80 and arch/z16 don't provide __INTMAX_TYPE__ or __UINTMAX_TYPE__.
@patacongo is it right?

Very unlikely. It is c89 which is before stdint.h

in that case, those types.h need to be updated to provide _intmax_t and _uintmax_t.

You will need to add those.

[yamt]

i guess compilers used for arch/z80 and arch/z16 don't provide __INTMAX_TYPE__ or __UINTMAX_TYPE__.
@patacongo is it right?

Very unlikely. It is c89 which is before stdint.h

in that case, those types.h need to be updated to provide _intmax_t and _uintmax_t.

You will need to add those.

thank you. i added them.

[yamt]

Yes, it is used, but all configs can build fine by removing compiler_stdint.h. So I think it is redundant and should be removed.

• the majority of configs relies on it providing _uintmax_t and _intmax_t.

If we make uint64_t/int64_t same as compiler want, can typedef uintmax_t/intmax_t to uint64_t/int64_t match compiler expectation?
If the answer is false, I still prefer to typedef _uintmax_t and _intmax_t in arch's inttype.h like other type, because the consistence is also important:

No Short Cuts
Reducing effort at the expense of Quality, Portability, or Consistency.

ok, it makes sense.

• it serves as an assertion to ensure the compiler types matches arch types.h.

The printf annotation can do the same thing, right?

i don't know how compiler printf format checks works wrt default type promotion.
even if it works, i don't think it's a good idea to rely on that level of details.

But, since all libc funcitons are implemented by NuttX self, how to map these basic types should be determined by NuttX too. We have to match the compiler expectation here, just because we want to utilize the printf/scanf format specifier chceck provided by compiler. So it's reasonable to limit the mismatch in printf/scanf format checker.

libc is just a part of C runtime. the compiler is also a fundamental part of it.
it's better to ensure type expectations matched unless you are seeking problems.

having said that, i dropped the compiler_stdint.h stuff from this PR because it turned out to be more controversial than i expected.

[xiaoxiang781216]

@yamt after reviewing the final patchset, I found that the common typedef for intmax_t/uintmax_t in include/stdint.h:

#ifdef __INT64_DEFINED
typedef _int64_t            intmax_t;
typedef _uint64_t           uintmax_t;
#else
typedef _int32_t            intmax_t;
typedef _uint32_t           uintmax_t;
#endif

should work fine after we correct _int64_t/_uint64_t/_int32_t/_uint32_t. Why we move intmax_t/uintmax_t to arch/inttype.h?

[yamt]

@yamt after reviewing the final patchset, I found that the common typedef for intmax_t/uintmax_t in include/stdint.h:

#ifdef __INT64_DEFINED
typedef _int64_t            intmax_t;
typedef _uint64_t           uintmax_t;
#else
typedef _int32_t            intmax_t;
typedef _uint32_t           uintmax_t;
#endif

should work fine after we correct _int64_t/_uint64_t/_int32_t/_uint32_t. Why we move intmax_t/uintmax_t to arch/inttype.h?

• you suggested it's better to have them in arch types.h for consistency with other types and i agreed.
• the common definition doesn't work well for macOS:

spacetanuki% cc -dM -E - < /dev/null|grep -E "__INT(32|64|MAX)_TYPE__"
#define __INT32_TYPE__ int
#define __INT64_TYPE__ long long int
#define __INTMAX_TYPE__ long int
spacetanuki% 

[xiaoxiang781216]

• the common definition doesn't work well for macOS:

spacetanuki% cc -dM -E - < /dev/null|grep -E "__INT(32|64|MAX)_TYPE__"
#define __INT32_TYPE__ int
#define __INT64_TYPE__ long long int
#define __INTMAX_TYPE__ long int
spacetanuki% 

Ok, thanks for explanation, it's clear now.

[xiaoxiang781216]

These two patch should merge into one:
9bc2c99
45a1d68

[yamt]

These two patch should merge into one:
9bc2c99
45a1d68

done

[xiaoxiang781216]

LGTM.