[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH] vmstate: constify VMStateField

From: Christian Borntraeger
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] vmstate: constify VMStateField
Date: Wed, 14 Nov 2018 18:00:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 11/14/2018 05:56 PM, Thomas Huth wrote:
> On 2018-11-14 17:49, Peter Maydell wrote:
>> On 14 November 2018 at 16:39, Philippe Mathieu-Daudé <address@hidden> wrote:
>>> Hi Thomas,
>>> On 14/11/18 17:29, Thomas Huth wrote:
>>>> Please don't. For rationale, see:
>>>> https://www.kernel.org/doc/html/v4.19/process/coding-style.html#typedefs
>>> Thanks for the pointer, I am interested in understanding why not do that.
>>> However in the link you pasted I don't see a rational about enforcing
>>> constness, I understand that since this case doesn't match the 5 rules, we
>>> should use 'struct VMStateField' directly and remove the typedef.
>> QEMU's coding style is not the kernel's. In the kernel, yes,
>> they prefer "struct foo". In QEMU we generally prefer to use
>> a typedef for most structs.
> Yes - my point was simply: Let's do not start to hide more things beside
> "struct" in a typedef. If I look at QEMU source code containing just a
> "VMStateField", I expect it to be a shortcut for "struct VMStateField".
> I'd never expect that it also contains the "const" attribute. I'm pretty
> sure that this would cause some confusion in the future otherwise.

I agree. typedefing a struct is one thing, typedefing qualifiers in (like const)
is getting really unexpected. 

reply via email to

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