RTEMS | Improve event record handling (!282)

[Chris Johns (@chris)]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20241111/d68db760/attachment-0001.htm>