[Libguestfs] [libnbd PATCH v3 02/29] generator/C.ml: use space consistently in func. and func.-like macro calls

Laszlo Ersek lersek at redhat.com
Mon Feb 20 16:21:52 UTC 2023


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 <lersek at 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 <eblake at redhat.com>
> 



More information about the Libguestfs mailing list