Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions

[Markus Armbruster]

Daniel P. Berrangé <address@hidden> writes:

> On Thu, Apr 11, 2019 at 02:20:27PM +0200, Markus Armbruster wrote:
>> 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().
>
> In this case it is a pretty trivial search & replace to do. The main
> hard bit would be syncing with various maintainer trees. Global cleanups
> are more work if you need to feed patches in via several different trees,
> as opposed to one tree-wide series.

Yes, it's a hassle.  I doubt it's worthwhile.  Anyway, unless somebody
does this work, ARRAY_SIZE() will surely stay.

>> 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*?
>
> elements of the variable that you are passing into the macro.

I pass a GSList * variable.