Hi,
On 27 February 2017 at 14:24, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> On Fri, 2017-02-24 at 01:08 +0100, Andrew Zaborowski wrote:
>> Also related to this I find that the HWSIM_ATTR_RADIO_NAME attributes
>> emitted contain the name string and are exactly of the right length
>> while the HWSIM_ATTR_RADIO_NAME attributes received by the kernel are
>> assumed to be NUL-terminated.
>
> I'll agree this is a bit strange - I guess it's too late to fix now
> though since userspace might assume "length/data" is the string, rather
> than "0-terminated" (especially if there's something like python
> userspace where strings can trivially contain NUL bytes).
>
> nla_put_string() would have added the NUL byte.
>
>> Is there a guarantee that a 0-byte
>> follows an attribute, or should this be changed for consistency?
>
> [HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },
>
> enforces that a NUL byte *must* be present when userspace gives us the
> information, so we're save - just asymmetric.
It seems that would be NLA_NUL_STRING, whlie for NLA_STRING it's
optional, I know because I didn't add the NUL in my userspace and
things still worked. We can copy the received nla_data into a buffer
and add the 0-byte there to support this as an option. I don't have a
problem with the asymmetric usage though.
>
> Anyway, patch applied.
Thanks
Best regards
