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: <aJ5y-WWCZAlJ9QUy@mini-arch>
Date: Thu, 14 Aug 2025 16:36:25 -0700
From: Stanislav Fomichev <stfomichev@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Stanislav Fomichev <sdf@...ichev.me>, netdev@...r.kernel.org,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	donald.hunter@...il.com, horms@...nel.org, jstancek@...hat.com,
	jacob.e.keller@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] tools: ynl: make ynl.c more c++ friendly

On 08/14, Jakub Kicinski wrote:
> On Thu, 14 Aug 2025 09:44:13 -0700 Stanislav Fomichev wrote:
> > Compiling ynl.c in a C++ code base requires invoking C compiler and
> > using extern "C" for the headers. To make it easier, we can add
> > small changes to the ynl.c file to make it palatable to the native
> > C++ compiler. The changes are:
> > - avoid using void* pointer arithmetic, use char* instead
> > - avoid implicit void* type casts, add c-style explicit casts
> > - avoid implicit int->enum type casts, add c-style explicit casts
> > - avoid anonymous structs (for type casts)
> > - namespacify cpp version, this should let us compile both ynl.c
> >   as c and ynl.c as cpp in the same binary (YNL_CPP can be used
> >   to enable/disable namespacing)
> > 
> > Also add test_cpp rule to make sure ynl.c won't break C++ in the future.
> 
> As I mentioned in person, ynl-cpp is a separate thing, and you'd all
> benefit from making it more C++ than going the other way and massaging
> YNL C.
> 
> With that said, commenting below on the few that I think would be okay.

Ok, and the rest (typecasts mostly and the namespace) - you're not supper
happy about? I can drop that test_cpp if that helps :-)

> > @@ -224,7 +228,7 @@ static inline void *ynl_attr_data_end(const struct nlattr *attr)
> >  
> >  #define ynl_attr_for_each_payload(start, len, attr)			\
> >  	for ((attr) = ynl_attr_first(start, len, 0); attr;		\
> > -	     (attr) = ynl_attr_next(start + len, attr))
> > +	     (attr) = ynl_attr_next((char *)start + len, attr))
> 
> okay
> 
> > @@ -149,7 +153,7 @@ ynl_err_walk(struct ynl_sock *ys, void *start, void *end, unsigned int off,
> >  		return n;
> >  	}
> >  
> > -	data_len = end - start;
> > +	data_len = (char *)end - (char *)start;
> 
> can we make the arguments char * instead of the casts?

Let me try. That might require to char-ify helpers like ynl_nlmsg_data_offset
and ynl_nlmsg_end_addr.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ