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

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

There needs to be an understanding of these APIs and how they are implemented. 
My understanding is GCC depends on C library interfaces which newlib supplies 
and if they are built on FreeBSD that is fine. The issue is when the `score` , 
`rtems` and `sapi` code reference or calls newlib. An example I have been 
pushing back on with @joel is the 2100 problem and the initial version made 
newlib calls. Newlib is free to change how it works and that adds a complexity 
to our project to manage I do not think is worth the save of that call. That 
code like this bit map code is the same. So I am being consistent here and I am 
also calling it out when I see it so it is discussed.

There has been a code containment understanding with the `score`, `sapi` and 
`rtems` that existed before I joined the project so lets be polite and say a 
long time and a decade or two before you joined. This has been watered down 
without a clear and open discussion and without suitable understanding.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1096#note_144129
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

Reply via email to