Eric Blake <ebl...@redhat.com> 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 <ebl...@redhat.com> Patch looks good.
