__rt_ffs 返回值为 0 的疑问

曾经官网上有人提了个问题 调度器这块是不是有漏洞
他说，__rt_ffs 函数可以返回 0 ，但是返回值是 0 的时候，所有调用这个函数的地方都把返回值减了 1，这样所有使用的地方当数组索引就会出现 -1 索引。
当时，我反问他，__rt_ffs 函数会返回 0 吗，或者说输入参数 rt_thread_ready_priority_group 会是 0 吗？个人理解，因为 idle 线程的存在 rt_thread_ready_priority_group 总是有值的，不会出现 0 的情况。
而且，实际情况也确实是，不允许出现 0，出现 0 意味着肯定有无法修复的错误出现了，这种情况。 if (value == 0) return value; 判断再多么严谨也没实际意义。

今天，在一款 arm9 芯片上测试 #5063 的时候发现了两个问题：

1. keil 里编译的汇编代码，求模运算竟然是 EB00444F BL __aeabi_uidiv 内置函数调用，这样一来，好像汇编代码也没少，反而更多了。
2. 所有的 __rt_ffs 实现都向 __builtin_ffs 实现看齐，特意进行加 1 ，然后在调用的地方再减去 1。这个不能向应用看齐？return __builtin_ffs()-1; 其它的 __rt_ffs 返回值从 0 到 31。如果觉得函数名可能会出现歧义，改个名字。

Start by reviewing the __rt_ffs implementations and their call sites, especially uses of rt_thread_ready_priority_group, then compare them with __builtin_ffs. Reproduce the ARM9/Keil case associated with #5063 and inspect the __aeabi_uidiv-generated modulo code. Done means the expected return-value convention and the impact of the generated assembly are established clearly.