On Wed, Oct 07, 2020 at 01:26:53PM -0600, Shuah Khan wrote: > On 10/7/20 12:11 PM, Kees Cook wrote: > > My instinct is to say leave it "int" and adjust documentation, which is > > the least disruptive, but I am enticed by the desire to make sure a > > counter doesn't "misbehave" and go negative when the usage wants it > > always positive. > > > > I would recommend leaving it as "int". Changing the API to unsigned has > other ramifications and cascading changes. > > My quick search shows me there are 612 atomic_inc_return usages and > 14 out of them are forcing the return type from int to u32. > > For atomic_read the numbers are 51 out of 5833 forcing u32. We have > couple of options: > > 1. Update the documentation since we have more cases where > int is just fine. > 2. Add counter_atomic32_inc_return_u32() variant to cover these few > cases that are forcing the return. > > I recommend going with option 1 with Documentation update and add > option 2 when we convert one of these 60+. Agreed: 1 seems best, and then later 2 if it feels justified. :) -- Kees Cook