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.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
