RTEMS | Improve event record handling (!282)

[Gedare Bloom (@gedare)]

Gedare Bloom commented on a discussion on cpukit/include/rtems/record.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/282#note_114623

 > + *
 > + * The structure shall be initialized by rtems_record_fetch_initialize().
 > + */
 > +typedef struct {
 > +#ifdef RTEMS_SMP
 > +  /**
 > +   * @brief This member contains the index of the processor from which the next
 > +   *   records are fetched.
 > +   */
 > +  uint32_t cpu_index;
 > +#endif
 > +  /**
 > +   * @brief This member contains the count of records which need to be fetched
 > +   *   from the current processor before the next processor is selected.
 > +   */
 > +  size_t cpu_todo;

I don't agree with the analogy. `calloc` uses both its parameters to construct a size in bytes, so the types need to be multiplied safely together to create a `size_t`. The `size_t` has a well-defined origin as the return type of `sizeof`. It doesn't make a lot of sense to use it for something that is not related to object sizes in the units of sizeof. If the `cpu_todo` is multipled by the size of the record to get the number of bytes to transfer, then I would be convinced. But it is not, it is just being used to keep track of how many items are left. Positive counters should just be some kind of unsigned integer type. It's a minor point, but this structure is part of the API between the record event recording and the client, so it should be done properly.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/282#note_114623
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/20241109/9f52074e/attachment-0001.htm>