[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 4/9] pci: use uint64_t for bar addr and size ins
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH 4/9] pci: use uint64_t for bar addr and size instead of uint32_t. |
Date: |
Thu, 1 Oct 2009 14:26:52 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
On Thu, Oct 01, 2009 at 04:15:59PM +0400, malc wrote:
> On Thu, 1 Oct 2009, Michael S. Tsirkin wrote:
>
> > On Wed, Sep 30, 2009 at 09:59:11PM +0400, malc wrote:
> > > On Wed, 30 Sep 2009, Michael S. Tsirkin wrote:
> > >
>
> [..snip..]
>
> > > > >
> > > > > _t suffix is reserved by POSIX.
> > > >
> > > > There's still no better naming for scalars. Worst case some platform
> > > > will fail to compile, and we'll rename.
> > > >
> > >
> > > Not good enough, if you are using something you have to abide the
> > > constraints.
> >
> > So, posix does not reserve all of *_t namespace, it would negate years
> > of C code. It simply says posix implementations can add only symbols
> > ending with _t in the headers: this is a constraint on posix headers,
> > not on applications that use them. Thus you have to find some other
> > means to avoid conflict if you have symbols ending with _t. Using your
> > module name as a prefix is a classical way to do this, for pci prefixing
> > type name with pci_ should be enough to prevent any issues.
>
> I don't understand this at all. POSIX says that if you include any of
> it's headers be prepared to deal with it, i.e. any of your own
> typedefs that end with _t are potentially clashing with what's defined
> there,
In practice I don't expect any posix header to clash with
michael_s_tsirkin_t even though in theory it might.
So you can choose not to use any types that end with _t and have a
guarantee that you won't clash with posix, and just name types sanely so
they don't clash with posix in practice, on any platform people care
about, like 99% of the world does.
> similarly identifiers that start with 'str', 'E', double
> underscore and underscore followed by a capital letter are reserved by
> C, you just don't go there.
I agree, double underscores look ugly enough to avoid them without a special
reason, but for everyone reading C, *_t means "scalar type"
and this benefit of using it outweights, IMO, the danger of
potential clash with a header on a non-existing platform.
> --
> mailto:address@hidden