Re: [Qemu-devel] [PATCH 4/9] pci: use uint64_t for bar addr and size instead of uint32_t.

[Jamie Lokier <jamie@shareable.org>]

malc wrote:
> 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, 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.

What's missing from that picture is there are _lots_ of other
identifiers not covered by the rule which also potentially clash with
your own, depending on vagaries of OSes, many extensions are not
covered by that POSIX rule but you still mustn't clash with them, and
the third-party libraries you typically link with have to be avoided too.

Not just header file clashes, but link-time or run-time problems due
to clashing with names not declared in the header files you included
too.  Defining your own 'valloc' function (with it's own meaning) will
probably cause a run-time failure in some library you might link to,
even though that's not a POSIX reserved identifier so nobody broke the
official rules.  Even defining your own 'error' function can be a
problem - I've seen applications break because they did that, and some
library they were linked to depended on the function of that name in
libc.

In other words, POSIX isn't a complete rule - it's a guideline, but
following it won't make you safe, and breaking it won't put you in
serious danger if you pick sensible names.  There is no absolute.

Since there are no absolutes anyway, sometimes the clarify benefits of
a readable name like 'ram_addr_t' outweight the concerns about
potential clash on some platform - even though it's not hard to
imagine some obscure system header file which has a definition of that name.

Also, Consider what happens when you make a library that's intended to
be used by lots of different applications.  Is it better to declare
that your library is in fact part of the "system" and therefore
justify using names like mylib_thing_t and _mylib_private_thing, so
that user apps are unlikely to clash with your library (but you have
to check compatibility with actual OSes), or is it better to use
mylib_thing and mylib_private_thing only, reduce POSIX clashes (not
100% avoidance due to OS extensions), and risk increased amounts of
clashes with apps using your library instead?  The answer is there
isn't a clear answer, you have to be pragmatic.  Depending on sane
prefixes that are unlikely to clash is a common pragmatic choice.

Of course if writing code which is guaranteed to work on any POSIX
platform is you're overriding objective, then following the POSIX rule
strictly makes sense.

-- Jamie