RTEMS | Use unsigned type for processor masks (!1096)

[Chris Johns (@chris)]

Chris Johns commented on a discussion on cpukit/include/rtems/score/processormaskimpl.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1096#note_144219

 >    uint32_t              index
 >  )
 >  {
 > -  long bits = mask->__bits[ index / _BITSET_BITS ];
 > +  unsigned long bits = mask->__bits[ index / _BITSET_BITS ];

Does this MR mask the issue in newlib? Is it wise to do that here?

---

Yes I am digging deep in this MR to highlight the issues we have around these sorts of changes that happen in newlib. I like the MR in our Contrib/newlib-cygwin project you provided a link too. It is a good approach to updating this sensitive area in our newlib code however there was no link or reference here to it and a link would have helped a lot. It maybe nice to have these MRs appear in our release notes? I am not sure how easy that would be but I can look if you think it is worth doing?

It would be good to document and understand our dependence on FreeBSD code in newlib? A users.rtems.org post with a list would be a welcomed start. I hope you appreciate how hard it was to piece together the bits related to this change from the limited information provided in the description. The simpler it is to review a change the quicker it will be approved.

I will look at https://gitlab.rtems.org/rtems/tools/rtems-source-builder/-/issues/136 to see what can be done. I have some ideas I will document there. It will require a change to the `rtems.git` build system system and I would welcome your help there. The outcome of that change to the RSB is to highlight changes in newlib that effect `rtems.git`. If the changes have been reviewed in the RTEMS project before entering newlib I see no reason to block RSB MRs that update the build data. You will not be able to update `rtems.git` until the RSB has been updated. I hope this adds suitable checks into the process.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1096#note_144219
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/20260304/92a4aaed/attachment-0001.htm>