On Mon, Nov 10, 2025 at 09:53:22AM +0100, Morten Brørup wrote: > > From: fengchengwen [mailto:[email protected]] > > > > Acked-by: Chengwen Feng <[email protected]> > > > > On 11/7/2025 11:49 PM, Bruce Richardson wrote: > > > From: Stephen Hemminger <[email protected]> > > > > > > Add RTE_MIN3() to handle case of RTE_MIN(RTE_MIN(...)), and similarly > > > add RTE_MAX3(). > > Do we need RTE_MIN3_T()/RTE_MAX3_T() macros too? > > > > Change name of local temporary variables in RTE_MAX() > > > to allow for combinations of RTE_MIN(RTE_MAX(...)) without causing > > > shadow declaration warnings. > > Consider making the local temporary variables in RTE_MIN() more unique too, > in case the macro is combined with some other macro also using _a and _b. >
Yes, that's possible. If I remember, I'll try and tweak this again if I do a new version of the set. > <feature creep> > Maybe an RTE_MINMAX(min,max,val) would be useful? > Same about RTE_MINMAX_T(min,max,val,type)? > </feature creep> > Not sure that is worth doing. Also, the naming gets weird and confusing, is the "max" parameter the parameter that would be passed to the MAX macro, i.e. the minimum value, or the actual maximum value you want to clamp. Therefore, if we were to have such an API, I'd avoid min-max in macro name entirely, and call it "RTE_BOUND" for example. Again, though, I don't think it's a high priority addition and won't do in a new version of this set. > > > > > > Signed-off-by: Stephen Hemminger <[email protected]> > > > Signed-off-by: Bruce Richardson <[email protected]> > > With or without suggested additions, > Acked-by: Morten Brørup <[email protected]> >
