qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>,
	Maxim Levitsky <mlevitsk@redhat.com>,
	qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"John Snow" <jsnow@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [PATCH v6 04/14] block/amend: separate amend and create options for qemu-img
Date: Fri, 15 May 2020 12:24:14 -0500	[thread overview]
Message-ID: <3a2238b4-e040-e327-a7dd-831e3f24c808@redhat.com> (raw)
In-Reply-To: <c93d9e92-94dc-9965-e291-2aef8724385a@redhat.com>

On 5/15/20 1:22 AM, Max Reitz wrote:

>>>
>>>> +        QCOW_COMMON_OPTIONS,
>>>> +        { /* end of list */ }
>>
>> ...the intended usage is to use the macro name followed by a comma, so
>> including a trailing comma in the macro itself would lead to a syntax
>> error.
> 
> But why is that the indended usage?  Is there something in our coding
> style that forbids macros that don’t allow a separator to be placed
> after them?

If we have more than one such macro, it is easier to write and indent 
(especially when using your editor's ability to decipher enough syntax 
to suggest how to indent):

myarray = {
   COMMON_ELEMENTS,
   MORE_ELEMENTS,
   { /* end of list */ }
};

than it is:

myarray = {
   COMMON_ELEMENTS
   MORE_ELEMENTS
   { /* end of list */ }
};

which in turn implies that it is better to NOT stick a trailing comma in 
the macro itself.  Similarly, for macros intended to replace statements, 
we tend to avoid the trailing ; in the macro itself, because it is 
easier to read:

{
   code;
   MACRO();
   more code;
}

than it is:

{
   code;
   MACRO()
   more code;
}

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2020-05-15 17:25 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-10 13:40 [PATCH v6 00/14] LUKS: encryption slot management using amend interface Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 01/14] qcrypto/core: add generic infrastructure for crypto options amendment Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 02/14] qcrypto/luks: implement encryption key management Maxim Levitsky
2020-05-14 11:56   ` Max Reitz
2020-05-17  8:13     ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 03/14] block/amend: add 'force' option Maxim Levitsky
2020-05-14 12:18   ` Max Reitz
2020-05-17  8:15     ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 04/14] block/amend: separate amend and create options for qemu-img Maxim Levitsky
2020-05-14 12:28   ` Max Reitz
2020-05-14 16:10     ` Eric Blake
2020-05-15  6:22       ` Max Reitz
2020-05-15 17:24         ` Eric Blake [this message]
2020-05-17  8:47           ` Maxim Levitsky
2020-05-17  8:54     ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 05/14] block/amend: refactor qcow2 amend options Maxim Levitsky
2020-05-14 13:36   ` Max Reitz
2020-05-17 17:52     ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 06/14] block/crypto: rename two functions Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 07/14] block/crypto: implement the encryption key management Maxim Levitsky
2020-05-14 14:09   ` Max Reitz
2020-05-14 14:14     ` Daniel P. Berrangé
2020-05-14 14:32       ` Max Reitz
2020-05-17 17:56         ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 08/14] block/qcow2: extend qemu-img amend interface with crypto options Maxim Levitsky
2020-05-14 14:30   ` Max Reitz
2020-05-17 18:03     ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 09/14] iotests: filter few more luks specific create options Maxim Levitsky
2020-05-14 14:49   ` Max Reitz
2020-05-17 18:50     ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 10/14] iotests: qemu-img tests for luks key management Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 11/14] block/core: add generic infrastructure for x-blockdev-amend qmp command Maxim Levitsky
2020-05-14 15:47   ` Max Reitz
2020-05-18 10:48     ` Maxim Levitsky
2020-05-10 13:40 ` [PATCH v6 12/14] block/crypto: implement blockdev-amend Maxim Levitsky
2020-05-14 16:05   ` Max Reitz
2020-05-10 13:40 ` [PATCH v6 13/14] block/qcow2: " Maxim Levitsky
2020-05-14 16:05   ` Max Reitz
2020-05-10 13:40 ` [PATCH v6 14/14] iotests: add tests for blockdev-amend Maxim Levitsky
2020-05-10 14:37 ` [PATCH v6 00/14] LUKS: encryption slot management using amend interface no-reply
2020-05-10 15:14 ` no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a2238b4-e040-e327-a7dd-831e3f24c808@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mlevitsk@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).