On 21.04.23 11:35, Johannes Berg wrote:
To me, the first question is if there are potentially any users that are
_relying_ on the current behaviour. This seems unlikely though, looking
at the ~30 users, most sound like signal/rssi, packet sizes, etc.
So let's say with the bug found here that prompted this patch, chances
are that there aren't any users that really want 0 to be special. I also
can't even really think of a reason for wanting that.
So then let's say we want to fix the existing code. I can think of these
possible ways:
* splitting off a bit for initialized from the unsigned long
(which at least for 64-bit should be OK since presumably most code
using this will run on 32-bit systems too)
* adding another value for it, e.g. making it u32 and adding a bool for
"first value"
* biasing the value, like Felix proposes, could be by 1 or -1 for
example
All of these have a memory cost, of course, though the first two are
data and the second code, so for things like stations the code exists
only once and the data multiple times. On 64-bit we can probably make
the first two not have a data memory cost though.
As for biasing the value, couldn't that lead to a similar problem? It's
clearly less likely that the end of the range is reached rather than
zero, but still?
I don't see how it can reduce the range in any way, since the bias is
added to the fractional part. A range reduction would seem to imply
having an average value that's bigger than the maximum allowed shifted
input (top bits cut off), and I don't think that's possible.
- Felix
