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