Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/282#note_114668 @gedare I suggest you reach out to the Open Group to ask why the object number in `calloc` is `size_t`? It would be interesting to know their view. It be related to C++'s view of [std::size_t](https://en.cppreference.com/w/cpp/types/size_t): > `std::size_t` is commonly used for array indexing and loop counting. Programs > that use other types, such as unsigned int, for array indexing may fail on, > e.g. 64-bit systems when the index exceeds > [UINT_MAX](https://en.cppreference.com/w/cpp/types/climits > "cpp/types/climits") or if it relies on 32-bit modular arithmetic. My experience of `int` of `unsigned int` being used as counts or sizes with code from a team of developers is problems soon appear. Signed vs unsigned is not often considered when selecting the size type nor is 32bit vs 64bit and that leads to a web of compiler warnings, sometime complex, often only seen on some compilers when porting code. MSC is good at being trough on this stuff. To deal with this quickly a team starts adding casts around comparisons and loops or calls, eg to `calloc` or C++ containers, to suppress the warnings and as the number of casts grow they become a source of bugs because they could be suppressing valid warnings. In C++ code I work on you need to have a _very_ good reason to have a cast and using `size_t` for size with counts and loop helps. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/282#note_114668 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
