From: Jakub Kicinski <kuba@kernel.org>
To: Stanislav Fomichev <sdf@fomichev.me>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, donald.hunter@gmail.com, horms@kernel.org,
jstancek@redhat.com, jacob.e.keller@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] tools: ynl: make ynl.c more c++ friendly
Date: Thu, 14 Aug 2025 15:27:07 -0700 [thread overview]
Message-ID: <20250814152707.6d16c342@kernel.org> (raw)
In-Reply-To: <20250814164413.1258893-1-sdf@fomichev.me>
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.
> @@ -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?
> static void ynl_err_reset(struct ynl_sock *ys)
> {
> - ys->err.code = 0;
> + ys->err.code = YNL_ERROR_NONE;
sure
> @@ -56,6 +60,11 @@ struct ynl_family {
> unsigned int ntf_info_size;
> };
>
> +struct ynl_sock_mcast {
struct ynl_mcast_grp
> + unsigned int id;
> + char name[GENL_NAMSIZ];
> +};
next prev parent reply other threads:[~2025-08-14 22:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 16:44 [PATCH net-next] tools: ynl: make ynl.c more c++ friendly Stanislav Fomichev
2025-08-14 21:29 ` Jacob Keller
2025-08-14 22:27 ` Jakub Kicinski [this message]
2025-08-14 23:36 ` Stanislav Fomichev
2025-08-15 0:05 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250814152707.6d16c342@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=jstancek@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.