On Tue, Aug 28, 2012 at 05:24:40PM +0100, Peter Maydell wrote: > On 28 August 2012 17:01, Michael S. Tsirkin <m...@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