Re: [Qemu-devel] [PATCH] HACKING: remove bogus restrictions

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Aug 28, 2012 at 05:24:40PM +0100, Peter Maydell wrote:
> On 28 August 2012 17:01, Michael S. Tsirkin <mst@redhat.com> wrote:
> > We copied HACKING from libvirt but it has some bogus stuff:
> > neither underscore capital, double underscore, or underscore 't' suffixes
> > are reserved in Posix/C: this appears to be based on misreading of the
> > C standard. Using sane prefixes is enough to avoid conflicts.

> > -2.4. Reserved namespaces in C and POSIX
> > -Underscore capital, double underscore, and underscore 't' suffixes should be
> > -avoided.
> 
> I think this is just a missing "prefixes". C99 7.1.3
> reserves underscore capital and double underscore prefixes.

This is taking it out of context - reserved means different
things in different parts of the spec.

As far as I can see, 7.1.3 talks about what is permissible in headers:
naturally when a libc implementation adds stuff in a header it would
want to avoid breaking applications including this header. But
it does not talk about what is permissible in a legal program - to avoid
conflicts, you just need to use variables with reasonable names like
kvmXXX qemuXXX or virtioXXX.

So it does not look like this is a reason to not use __kvm_pv_eoi_disabled.

Chances that a libc header predefines this name are zero.

> POSIX reserves _t if any POSIX header is defined (POSIX.1-2008 section
> 2.2.2, http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html)

Same thing really.
So this says posix implementations can add types ending with _t in any
header.  It does not prohibit applications from using such names
in a reasonable manner, and it does not look like this is a reason to
not use qemu_foo_bar_t.


> I would suggest that the section is reworded to:
> 
> # Underscore capital and double underscore prefixes are reserved
> # by the C standard. Underscore 't' suffixes are reserved by POSIX.
> # They should be avoided in QEMU code.
> 
> -- PMM

This might be nice from language purism point of view
but ignores the fact that QEMU already uses lots of these.
Specifically a _t type is even mentioned in HACKING itself.

So the benefit to excluding this in new code is marginal.


-- 
MST