linux-kernel - Re: [PATCH net-next] tools: ynl: make ynl.c more c++ friendly

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250814170514.3fb6e690@kernel.org>
Date: Thu, 14 Aug 2025 17:05:14 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Stanislav Fomichev <stfomichev@...il.com>
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 Thu, 14 Aug 2025 16:36:25 -0700 Stanislav Fomichev wrote:
> > 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 :-)

No, they are illogical from C's standpoint :(
I really don't get the need for the adjustments, the code generator is
obviously different for C++, and that's a major effort. The ynl.c casts
are trivial in comparison.
 
> > > @@ -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.

Hm, then probably let's leave it as void *