From: "Andreas Färber" <afaerber@suse.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
Erik Blake <eblake@redhat.com>,
qemu-devel@nongnu.org, Zhi Yong Wu <wuzhy@cn.ibm.com>,
Blue Swirl <blauwirbel@gmail.com>,
Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 01/16] net: Add a hub net client
Date: Mon, 23 Jul 2012 18:33:43 +0200 [thread overview]
Message-ID: <500D7CE7.9040903@suse.de> (raw)
In-Reply-To: <CAJSP0QULUhcMzyet9eZzki8KMztRiY9czGWyMbrQS=qbjHKZnA@mail.gmail.com>
Am 23.07.2012 17:23, schrieb Stefan Hajnoczi:
> On Mon, Jul 23, 2012 at 4:16 PM, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 07/23/12 16:52, Stefan Hajnoczi wrote:
>>> On Mon, Jul 23, 2012 at 3:05 PM, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>>>> The idea is, rather than
>>>>
>>>> unsigned int id = hub->num_ports++;
>>>>
>>>> it should say
>>>>
>>>> unsigned int id;
>>>> /* ... */
>>>> id = hub->num_ports++;
>>>
>>> "Be careful to not obfuscate the code by initializing variables in the
>>> declarations. Use this feature only thoughtfully. DO NOT use
>>> function calls in initializers."
>>>
>>> This?
>>>
>>> Do you know the rationale? It's not clear to me how this "obfuscates" the code.
>>
>> I think the rationale is that (a) people tend to reorganize definitions,
>> and the expressions in the initializer lists may depend on the original
>> order, (b) even worse with removal of variables, (c) many people have a
>> "conceptual divide" between the definition block and the logic below it,
>> and the first should set constant defaults at most. (Naturally this
>> prevents C99/C++ style mixing of definitions and code as well, at least
>> without explicit braces.)
>>
>> I'm one of those people, but again I'm not sure if qemu has any
>> guideline on this.
>>
>>
>>> Messing around with side-effects in a series of variable declarations
>>> with intializers could be bug-prone. But here there is only one
>>> initializer so it's not a problem.
>>>
>>> Regarding QEMU, there's no coding style rule against initializers.
>>> Personally I think that's a good thing because it keeps the code
>>> concise - people reading it don't have to keep the declaration in
>>> their mind until they hit the initializer later on.
>>
>> Well I keep the definitions at the top of the block so I can very easily
>> return to them visually (and be sure they do nothing else than define
>> variables / declare externs), but it's getting philosophical :)
>>
>> I have nothing against this initializer as-is, I just wanted to voice
>> *if* there's such a guideline in qemu *then* it should be followed :)
>
> Yes, I understand - it's a question of style or flamewar fodder :). I
> double-checked that there is no guideline in ./CODING_STYLE and
> ./HACKING.
Hm, I'm not so much into those documents [cc'ing Blue], but we used to
be stricter about ANSI C some years back (which iirc forbids
non-constant expressions in initializers?). FWIW we have since switched
to C99 struct initializers and use QOM cast macros (that translate to a
function call) in initializers. -ansi -pedantic is unlikely to get far.
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2012-07-23 16:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 12:01 [Qemu-devel] [PATCH 00/16] net: Move legacy QEMU VLAN code into net/hub.c Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 01/16] net: Add a hub net client Stefan Hajnoczi
2012-07-23 12:45 ` Laszlo Ersek
2012-07-23 13:49 ` Stefan Hajnoczi
2012-07-23 14:05 ` Laszlo Ersek
2012-07-23 14:52 ` Stefan Hajnoczi
2012-07-23 15:16 ` Laszlo Ersek
2012-07-23 15:23 ` Stefan Hajnoczi
2012-07-23 16:33 ` Andreas Färber [this message]
2012-07-23 17:11 ` Markus Armbruster
2012-07-23 19:01 ` Blue Swirl
2012-07-20 12:01 ` [Qemu-devel] [PATCH 02/16] net: Use hubs for the vlan feature Stefan Hajnoczi
2012-07-23 13:55 ` Laszlo Ersek
2012-07-23 14:56 ` Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 03/16] net: Look up 'vlan' net clients using hubs Stefan Hajnoczi
2012-07-23 15:04 ` Laszlo Ersek
2012-07-23 15:21 ` Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 04/16] hub: Check that hubs are configured correctly Stefan Hajnoczi
2012-07-23 19:15 ` Laszlo Ersek
2012-07-20 12:01 ` [Qemu-devel] [PATCH 05/16] net: Drop vlan argument to qemu_new_net_client() Stefan Hajnoczi
2012-07-23 19:35 ` Laszlo Ersek
2012-07-20 12:01 ` [Qemu-devel] [PATCH 06/16] net: Convert qdev_prop_vlan to peer with hub Stefan Hajnoczi
2012-07-23 20:07 ` Laszlo Ersek
2012-07-24 10:49 ` Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 07/16] net: Remove vlan code from net.c Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 08/16] net: Remove VLANState Stefan Hajnoczi
2012-07-23 20:57 ` Laszlo Ersek
2012-07-24 10:33 ` Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 09/16] net: Rename non_vlan_clients to net_clients Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 10/16] net: Rename VLANClientState to NetClientState Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 11/16] net: Rename vc local variables to nc Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 12/16] net: Rename qemu_del_vlan_client() to qemu_del_net_client() Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 13/16] net: Make "info network" output more readable info Stefan Hajnoczi
2012-07-23 21:54 ` Laszlo Ersek
2012-07-24 10:26 ` Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 14/16] net: cleanup deliver/deliver_iov func pointers Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 15/16] net: determine if packets can be sent before net queue deliver packets Stefan Hajnoczi
2012-07-20 12:01 ` [Qemu-devel] [PATCH 16/16] hub: add the support for hub own flow control Stefan Hajnoczi
2012-07-23 22:27 ` Laszlo Ersek
2012-07-24 6:42 ` Paolo Bonzini
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=500D7CE7.9040903@suse.de \
--to=afaerber@suse.de \
--cc=blauwirbel@gmail.com \
--cc=eblake@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.com \
--cc=wuzhy@cn.ibm.com \
--cc=wuzhy@linux.vnet.ibm.com \
/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).