All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sergey Fedorov <serge.fdrv@gmail.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 4/4] ARRAY_SIZE: check that argument is an array
Date: Fri, 20 Jan 2017 08:34:57 +0100	[thread overview]
Message-ID: <877f5q421q.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <459939cd-4f0e-bc08-7de8-5788e6f2e2aa@redhat.com> (Eric Blake's message of "Thu, 19 Jan 2017 17:00:52 -0600")

Eric Blake <eblake@redhat.com> writes:

> On 01/19/2017 04:11 PM, Michael S. Tsirkin wrote:
>
>>>> +#define QEMU_IS_ARRAY(x) (!__builtin_types_compatible_p(typeof(x), \
>>>> +                                                        typeof(&(x)[0])))
>>>>  #ifndef ARRAY_SIZE
>>>> -#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>>>> +#define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \
>>>> +                       QEMU_BUILD_BUG_ON_ZERO(!QEMU_IS_ARRAY(x)))
>>>
>>> We've got some double-negation going on here ("cause a build bug if the
>>> negation of QEMU_IS_ARRAY() is not 0") which takes some mental
>>> gymnastics, but it is the correct result.  [I kind of like that gnulib
>>> uses positive logic in its 'verify(x)' meaning "verify that x is true,
>>> or cause a build error"; compared to the negative logic in the kernal
>>> 'BUILD_BUG_ON[_ZERO](x)' meaning "cause a build bug if x is non-zero" -
>>> but that's personal preference and not something for qemu to change]
>> 
>> I can rename QEMU_IS_ARRAY to QEMU_IS_PTR and reverse the logic - would
>> this be preferable?
>
> No, that's worse. As written, "cause a build bug if x is not an array"
> is easier than "cause a build bug if x is a pointer", because now you
> are missing an implicit "(instead of the intended array)".  Keep it the
> way you have it.  I guess it's the _ZERO as a suffix that's throwing me;
> a better name might have been QEMU_ZERO_OR_BUILD_BUG_ON(x) ("give me a
> zero expression, or a build bug if x is non-zero") rather than
> QEMU_BUILD_BUG_ON_ZERO (my first read was "give me a build bug if x is
> zero", but a better read is "give me a build bug if x is not zero, else
> give me x because it is zero") - but our choice of naming in patch 3/4
> mirrors the kernel naming, so it's not worth changing.

Two ways to skin the assertion cat:

    assert must_be_true
    bug_on must_be_false

The C language picks the first one, both with assert() and with C11's
_Static_assert().  I'd prefer we stick to that, but I'm not asking you
to change your series.

  reply	other threads:[~2017-01-20  7:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-19 21:07 [Qemu-devel] [PATCH v3 0/4] ARRAY_SIZE fixups Michael S. Tsirkin
2017-01-19 21:07 ` [Qemu-devel] [PATCH v3 1/4] compiler: drop ; after BUILD_BUG_ON Michael S. Tsirkin
2017-01-19 21:22   ` Eric Blake
2017-01-19 21:07 ` [Qemu-devel] [PATCH v3 2/4] compiler: rework BUG_ON using a struct Michael S. Tsirkin
2017-01-19 21:26   ` Eric Blake
2017-01-20  7:44     ` Markus Armbruster
2017-01-20  7:42   ` Markus Armbruster
2017-01-20 16:57     ` Michael S. Tsirkin
2017-01-20 17:09       ` Paolo Bonzini
2017-01-20 17:45         ` Michael S. Tsirkin
2017-01-20 18:33           ` Markus Armbruster
2017-01-20  9:41   ` Dr. David Alan Gilbert
2017-01-20 14:36     ` Eric Blake
2017-01-20 14:53       ` Dr. David Alan Gilbert
2017-01-19 21:07 ` [Qemu-devel] [PATCH v3 3/4] compiler: expression version of QEMU_BUILD_BUG_ON Michael S. Tsirkin
2017-01-19 21:28   ` Eric Blake
2017-01-19 21:07 ` [Qemu-devel] [PATCH v3 4/4] ARRAY_SIZE: check that argument is an array Michael S. Tsirkin
2017-01-19 21:59   ` Eric Blake
2017-01-19 22:11     ` Michael S. Tsirkin
2017-01-19 23:00       ` Eric Blake
2017-01-20  7:34         ` Markus Armbruster [this message]
2017-01-20 12:20           ` Paolo Bonzini
2017-01-20  7:45 ` [Qemu-devel] [PATCH v3 0/4] ARRAY_SIZE fixups Markus Armbruster
2017-01-20 14:57 ` no-reply
2017-01-20 15:15 ` no-reply

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=877f5q421q.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=serge.fdrv@gmail.com \
    /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.