On Tue, 2019-10-15 at 18:21 +0100, Daniel P. Berrangé wrote: > On Tue, Oct 15, 2019 at 04:10:55PM +0200, Andrea Bolognani wrote: > > On Tue, 2019-10-15 at 14:21 +0200, Ján Tomko wrote: > > > -#define ARRAY_CARDINALITY(Array) (sizeof(Array) / sizeof(*(Array))) > > > +#define G_N_ELEMENTS(Array) (sizeof(Array) / sizeof(*(Array))) > > > > In this case, and in this case only, I think we should leave the name > > alone. > > > > When we use GLib and simply provide our own implementation when using > > a version that's too old, the GLib name is obviously accurate, but in > > this specific case I think it's misleading and we should stick with > > the current one. > > We do have the option to have our example programs use GLib instead > of plain C. If people are using libvirt from plain C, I'm inclined > to suggest they'd be wise to use GLib for the same reasons that it > is beneficial for libvirt to use GLib. > > If they're not using GLib, they likely have enough C knowledge to > figure out what they must do from our examples anyway. Introducing a dependency on GLib for the example sounds acceptable to me, and certainly better than defining G_* macros ourselves. One thing we could do, and which would be useful in general as well as being fairly common from what I've seen in other projects, is to have a comment at the start of the example file along the lines of /* event-test - listen to libvirt events * * Compile with: * * gcc -o event-test event-test.c \ * $(pkg-config --cflags --libs libvirt glib-2.0) */ At that point even people who are not that familiar with C, libvirt or GLib will be able to build and run the example. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
