yamt commented on pull request #2222: URL: https://github.com/apache/incubator-nuttx/pull/2222#issuecomment-729650746
> > > > > 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. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
