All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andriin@fb.com>,
	bpf@vger.kernel.org, netdev@vger.kernel.org, ast@fb.com,
	daniel@iogearbox.net
Cc: andrii.nakryiko@gmail.com, kernel-team@fb.com,
	Andrii Nakryiko <andriin@fb.com>
Subject: Re: [PATCH bpf-next] libbpf: make LIBBPF_OPTS macro strictly a variable declaration
Date: Mon, 21 Oct 2019 19:18:02 +0200	[thread overview]
Message-ID: <87r236ow51.fsf@toke.dk> (raw)
In-Reply-To: <20191021165744.2116648-1-andriin@fb.com>

Andrii Nakryiko <andriin@fb.com> writes:

> LIBBPF_OPTS is implemented as a mix of field declaration and memset
> + assignment. This makes it neither variable declaration nor purely
> statements, which is a problem, because you can't mix it with either
> other variable declarations nor other function statements, because C90
> compiler mode emits warning on mixing all that together.
>
> This patch changes LIBBPF_OPTS into a strictly declaration of variable
> and solves this problem, as can be seen in case of bpftool, which
> previously would emit compiler warning, if done this way (LIBBPF_OPTS as
> part of function variables declaration block).
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
>  tools/bpf/bpftool/prog.c |  6 +++---
>  tools/lib/bpf/libbpf.h   | 13 +++++++------
>  2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> index 27da96a797ab..1a7e8ddf8232 100644
> --- a/tools/bpf/bpftool/prog.c
> +++ b/tools/bpf/bpftool/prog.c
> @@ -1093,6 +1093,9 @@ static int load_with_options(int argc, char **argv, bool first_prog_only)
>  {
>  	struct bpf_object_load_attr load_attr = { 0 };
>  	enum bpf_prog_type common_prog_type = BPF_PROG_TYPE_UNSPEC;
> +	LIBBPF_OPTS(bpf_object_open_opts, open_opts,
> +		.relaxed_maps = relaxed_maps,
> +	);
>  	enum bpf_attach_type expected_attach_type;
>  	struct map_replace *map_replace = NULL;
>  	struct bpf_program *prog = NULL, *pos;
> @@ -1106,9 +1109,6 @@ static int load_with_options(int argc, char **argv, bool first_prog_only)
>  	const char *file;
>  	int idx, err;
>  
> -	LIBBPF_OPTS(bpf_object_open_opts, open_opts,
> -		.relaxed_maps = relaxed_maps,
> -	);
>  
>  	if (!REQ_ARGS(2))
>  		return -1;
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 0fdf086beba7..bf105e9e866f 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -77,12 +77,13 @@ struct bpf_object_open_attr {
>   * bytes, but that's the best way I've found and it seems to work in practice.
>   */
>  #define LIBBPF_OPTS(TYPE, NAME, ...)					    \
> -	struct TYPE NAME;						    \
> -	memset(&NAME, 0, sizeof(struct TYPE));				    \
> -	NAME = (struct TYPE) {						    \
> -		.sz = sizeof(struct TYPE),				    \
> -		__VA_ARGS__						    \
> -	}
> +	struct TYPE NAME = ({ 						    \
> +		memset(&NAME, 0, sizeof(struct TYPE));			    \
> +		(struct TYPE) {						    \
> +			.sz = sizeof(struct TYPE),			    \

Wait, you can stick arbitrary code inside a variable initialisation
block like this? How does that work? Is everything before the (struct
type) just ignored (and is that a cast)?

-Toke


  reply	other threads:[~2019-10-21 17:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21 16:57 [PATCH bpf-next] libbpf: make LIBBPF_OPTS macro strictly a variable declaration Andrii Nakryiko
2019-10-21 17:18 ` Toke Høiland-Jørgensen [this message]
2019-10-21 17:38   ` Andrii Nakryiko
2019-10-21 18:19     ` Yonghong Song
2019-10-21 19:01 ` Jakub Sitnicki
2019-10-21 23:51   ` Andrii Nakryiko
2019-10-22  7:27     ` Toke Høiland-Jørgensen

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=87r236ow51.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    /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.