[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions |
Date: |
Thu, 11 Apr 2019 14:20:27 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Daniel P. Berrangé <address@hidden> writes:
> On Tue, Apr 09, 2019 at 11:37:44AM +0200, Philippe Mathieu-Daudé wrote:
[...]
>> I remember this post from Daniel where he suggests sticking to GLib
>> G_N_ELEMENTS() (which looks similar to your suggestion):
>> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg02676.html
>>
>> $ git grep G_N_ELEMENTS|wc -l
>> 125
>> $ git grep ARRAY_SIZE|wc -l
>> 939
>>
>> Now it is not obvious to me to understand which GLib API we are
>> encouraged to use and which ones we shouldn't.
>
> We have a bunch of duplication that is essentially a historical
> artifact from before we used GLib in QEMU. IMHO, if GLib provides
> something that is equivalent with no functional downside that
> matters to QEMU, then there's no reason to keep QEMU's duplicate.
>
> IOW, I would always prefer GLib unless there's a compelling reason
> not to in order to minimize what we maintain ourselves
Without a tree-wide sweep, we won't ever stop maintaining ARRAY_SIZE().
As long as we maintain it anyway, I'd prefer it over G_N_ELEMENTS()
myself, because I consider latter name in poor taste: elements of
*what*?
Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions, Aleksandar Markovic, 2019/04/09
Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions, Peter Maydell, 2019/04/09
Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions, Liam Merwick, 2019/04/09