On 2/15/23 20:54, Eric Blake wrote: > On Wed, Feb 15, 2023 at 03:11:31PM +0100, Laszlo Ersek wrote: >> Apply the ideas in the previous patch to the C-language bindings >> generator. >> >> Signed-off-by: Laszlo Ersek <ler...@redhat.com> >> --- >> generator/C.ml | 20 ++++++++++---------- >> 1 file changed, 10 insertions(+), 10 deletions(-) >> > >> pr "#ifndef LIBNBD_ATTRIBUTE_NONNULL\n"; >> - pr "#if defined(__GNUC__) && LIBNBD_GCC_VERSION >= 120000 /* gcc >= 12.0 >> */\n"; >> - pr "#define LIBNBD_ATTRIBUTE_NONNULL(...) >> __attribute__((__nonnull__(__VA_ARGS__)))\n"; >> + pr "#if defined (__GNUC__) && LIBNBD_GCC_VERSION >= 120000 /* gcc >= 12.0 >> */\n"; >> + pr "#define LIBNBD_ATTRIBUTE_NONNULL(...) __attribute__ ((__nonnull__ >> (__VA_ARGS__)))\n"; > > Not only are these lines long in our source, they are long in the > generated libnbd.h. I would not be opposed to a followup patch that > tries harder at keeping the generated file under 80 columns (but there > are already places where that is harder than this snippet - such as > the generated declaration of nbd_aio_opt_list_meta_context), but it > does not need to happen in this patch.
Right, thanks -- if we agree we should have a new BZ for these subsequent tasks, I'll go over the comments again and capture them in the BZ. Laszlo > > And while I mentioned in 01/29 about the possibility of a C code > formatter as a CI step for *.[ch], it would be even harder to insist > that generated code matches a given style (it's always a nice goal for > generated files to be human-readable where possible, but I'd much > rather sacrifice that if it gets in the way of actually implementing > the generator concisely). > > Reviewed-by: Eric Blake <ebl...@redhat.com> > _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs