On Tue, 28 Aug 2012, Michael S. Tsirkin wrote:
> 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.
Reserved means - reserved for implementation to use as it sees fit,
for instance - 6.2.5
28) Implementation-defined keywords shall have the form of an identifier
reserved for any use as described in 7.1.3.
Future versions of C might define something in the form __xxx or _[A-Z]xxx
precisely because those are invalid for user to define.. (_Imaginary,
_Bool, whatever)
7.1.3#2
>
> As far as I can see, 7.1.3 talks about what is permissible in headers:
And you are wrong.
> 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.
>
>
>
--
mailto:av1...@comtv.ru
