Conversation

The Linux kernel include/linux/math.h header has macros

roundup(x, y)

and

round_up(x, y)

What do you think they do? Would you know the difference between the two without looking it up? What happens if you mix them up? How significant is the single underscore there?

4
0
1
@jani NO. I had to check never used them. I've done round_up manually :-) Actually where I've done manual "rounding", I'd rather keep it the way it is, than switch because it makes later on easier to recall... So I have question their usefulness actually but I don't mind them being there.
1
0
1

@jani I had no idea what the difference is, but looked them up.
I'm still not sure after reading the code what they do, but I'm sure I'd use the wrong one occasionally.

0
0
0
Given how wide they are spread, neither make sense to fix the naming. Something simple like roundup and roundup_pow2 would already bring some clarity.

Ofc you could make an inline function with a "better name", which calls round_up, and let subsystems progressively transform to that but probably not worth of time and energy :-)
0
0
0

Jarkko Sakkinen

Edited 1 year ago

@jani OK, did not check the implementation. I thought the point was to find the nearest power of two.

I’d probably use __fls() and << 1 unless the exact same number (i.e. already pow2). Like for the stuff I thought it was used for to be more specific… I guess I stay away from those functions, feels for me more complicated to use them than do what I want open-coded :-) Probably would end up using them in a wrong way…

0
0
1

@jani While both functions may be defined in math.h, they are not intended to be called dorectly. see https://en.cppreference.com/w/c/numeric/math/round for more information on rounding functions exposed by math.h.
You should ALWAYS refer to the documentation. Js and python developers are notorious for shitty documentation, and for believing that the user should make assumptions about the function of a thing (like a function's return value).

0
0
0

@jani Documentation should never leave room for assumptions.

0
0
0
@jani @TheKeymaker Documentation should merely document the parts that are neither obvious nor intuitive. This applies both to an inline comment and also header comment of a function...
1
0
1
@jani @TheKeymaker And to further underline: for parts that are not obvious, there must be also a solid reason why they are not obvious. I.e. those parts exist no matter how well the semantics are implemented. Otherwise, it should not IMHO pass the patch review process in the first place... I'm not saying that accepting such functions never happens to me but this is at least the ideal...
0
0
1
@jani Wow, nice list of people in the loop you have over there...
1
0
2
@jani @jarkko yeah I'm not having a go I mean it's just a pity that sometimes this is necessary...

And I've been shouted at for NOT doing this before btw...
0
0
2