[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZxplEne_oHXQycnc@hog>
Date: Thu, 24 Oct 2024 17:17:38 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Johannes Berg <johannes@...solutions.net>
Cc: linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] net: convert to nla_get_*_default()
2024-10-24, 16:52:00 +0200, Johannes Berg wrote:
> On Thu, 2024-10-24 at 16:48 +0200, Sabrina Dubroca wrote:
> >
> > If nla_get_*_default was a macro (generating an "attr ? getter :
> > default" expression) you wouldn't have that problem I think,
>
> Hmm. Perhaps. In the conditional operator (?:) they're subject to
> integer promotion though
Is it?
#define nla_get_u16_default(attr, d) (attr ? nla_get_u16(attr) : d)
int v = nla_get_u16_default(NULL, -1);
seems to put the correct value into v.
(but -ENOFOOD and -ELOWCOFFEE here, so I don't trust this quick test
much :))
>, I wonder if that could cause some subtle issue
> too especially if nla_get_u*() is used with signed variables?
The issue in that example is pretty subtle and I'm fairly sure people
are going to mess up :/
But I'm not attached to that macro I just suggested, it's just a
thought.
> > but you
> > couldn't nicely generate all the helpers with MAKE_NLA_GET_DEFAULT
> > anymore.
>
> Right, that too.
>
> I think it's probably better to just review them, and only commit the
> obvious ones originally?
Well, this one looked reasonable too. I'm not convinced reviewers are
going to catch those problems. Or authors of new code using those
_default helpers from the start.
--
Sabrina
Powered by blists - more mailing lists