netdev - Re: [PATCH net-next 05/11] tools: ynl-gen: define nlattr *array in a block scope

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250905171809.694562c6@kernel.org>
Date: Fri, 5 Sep 2025 17:18:09 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Asbjørn Sloth Tønnesen
 <ast@...erby.net>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>, Simon Horman
 <horms@...nel.org>, Jacob Keller <jacob.e.keller@...el.com>, Andrew Lunn
 <andrew+netdev@...n.ch>, wireguard@...ts.zx2c4.com, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 05/11] tools: ynl-gen: define nlattr *array in
 a block scope

On Thu,  4 Sep 2025 22:01:28 +0000 Asbjørn Sloth Tønnesen wrote:
> Instead of trying to define "struct nlattr *array;" in the all
> the right places, then simply define it in a block scope,
> as it's only used here.
> 
> Before this patch it was generated for attribute set _put()
> functions, like wireguard_wgpeer_put(), but missing and caused a
> compile error for the command function wireguard_set_device().
> 
> $ make -C tools/net/ynl/generated wireguard-user.o
> -e      CC wireguard-user.o
> wireguard-user.c: In function ‘wireguard_set_device’:
> wireguard-user.c:548:9: error: ‘array’ undeclared (first use in ..)
>   548 |         array = ynl_attr_nest_start(nlh, WGDEVICE_A_PEERS);
>       |         ^~~~~

Dunno about this one. In patch 4 you basically add another instance of
the "let's declare local vars at function level" approach. And here
you're going the other way. This patch will certainly work, but I felt
like I wouldn't have written it this way if I was typing in the parsers
by hand.