On Wed, Nov 20, 2019 at 01:12:56PM +0100, Stefano Brivio wrote: > On Wed, 20 Nov 2019 13:01:52 +0100 > Stefano Brivio <sbrivio@xxxxxxxxxx> wrote: > > > On Wed, 20 Nov 2019 12:24:48 +0100 > > Phil Sutter <phil@xxxxxx> wrote: > > > > [...] > > > > > > + if (!*l) > > > > + break; > > > > + v = *l; > > > > + mnl_attr_put_u32(nlh, NFTA_SET_SUBKEY_LEN, htonl(v)); > > > > > > I guess you're copying the value here because how htonl() is declared, > > > but may it change the input value non-temporarily? I mean, libnftnl is > > > in control over the array so from my point of view it should be OK to > > > directly pass it to htonl(). > > > > It won't change the input value at all, but that's not the point: I'm > > reading from an array of 8-bit values and attributes are 32 bits. If I > > htonl() directly on the input array, it's going to use 24 bits around > > those 8 bits. > > Err, wait, never mind :) I'm just passing the value, not the reference > there -- no need to copy anything of course. I'll drop this copy in v2. I wondered if htonl() may be implemented as a macro and therefore side-effects are indeed possible. In fact, the opposite is the case (declared with const attribute). Cheers, Phil
