Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Apr 11, 2019 at 02:20:27PM +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <berra...@redhat.com> 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.