qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/16] net: Add a hub net client


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 01/16] net: Add a hub net client
Date: Mon, 23 Jul 2012 19:01:17 +0000

On Mon, Jul 23, 2012 at 4:33 PM, Andreas Färber <address@hidden> wrote:
> Am 23.07.2012 17:23, schrieb Stefan Hajnoczi:
>> On Mon, Jul 23, 2012 at 4:16 PM, Laszlo Ersek <address@hidden> wrote:
>>> On 07/23/12 16:52, Stefan Hajnoczi wrote:
>>>> On Mon, Jul 23, 2012 at 3:05 PM, Laszlo Ersek <address@hidden> 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.

For example in block/vvfat.c, various initializers and nonstandard
stuff like variable length arrays have been used since day one. It's
not the finest example of code in QEMU though.

>
> 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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]