Chris Johns commented on a discussion on cpukit/include/rtems/score/processormaskimpl.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1096#note_144075 > uint32_t index > ) > { > - long bits = mask->__bits[ index / _BITSET_BITS ]; > + unsigned long bits = mask->__bits[ index / _BITSET_BITS ]; Thanks. This is the reasons I have concerns about the structuring of the code this way and having interdependent pieces that are not based on open standards. Here we have a key part of our kernel dependent on another project which means in theory any update to newlib should check these dependencies. What we have is relying on the files being in an RTEMS specific area and someone, you, knowing what and how to maintain them in an appropriate way. You are doing this however as a project it depend on you and I am not sure that is in the best interests of the project? Again, I am not conformable with this approach. Do these changes that create a churn with the tools put a halt to releasing RTEMS 7? If the bit macro code was in `contrib/cpukit` there would be no churn of the tools and no disturbance. I see the breaking of the orthogonal relationship of the tools and the score is a step backwards. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1096#note_144075 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
