qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v11 20/28] qapi: Forbid case-insensitive clashes


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v11 20/28] qapi: Forbid case-insensitive clashes
Date: Wed, 11 Nov 2015 15:53:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eric Blake <address@hidden> writes:

> In general, designing user interfaces that rely on case
> distinction is poor practice.  Another benefit of enforcing
> a restriction against case-insensitive clashes is that we
> no longer have to worry about the situation of enum values
> that could be distinguished by case if mapped by c_name(),
> but which cannot be distinguished when mapped to C as
> ALL_CAPS by camel_to_upper().

With PATCH 19, they're mapped by c_name(N).upper().

>                                Thus, having the generator
> look for case collisions up front will prevent developers
> from worrying whether different munging rules for member
> names compared to enum values as a discriminator will cause
> any problems in qapi unions.
>
> There is also the possibility that we may want to add a
> future extension to QMP of teaching it to be case-insensitive
> (the user could request command 'Quit' instead of 'quit', or
> could spell a struct field as 'CPU' instead of 'cpu').  But
> for that to be a practical extension, we cannot break
> backwards compatibility with any existing struct that was
> already relying on case sensitivity.  Fortunately, after the
> previous patch cleaned up CpuInfo, there are no such existing
> qapi structs.  Of course, the idea of a future extension is
> not as strong of a reason to make the change.
>
> At any rate, it is easier to be strict now, and relax things
> later if we find a reason to need case-sensitive QMP members,
> than it would be to wish we had the restriction in place.

Suggest to briefly mention the new test.

> Signed-off-by: Eric Blake <address@hidden>

Patch looks good.



reply via email to

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