From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtVH8-0007qA-7F for qemu-devel@nongnu.org; Thu, 01 Oct 2009 19:41:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtVH3-0007p7-Mv for qemu-devel@nongnu.org; Thu, 01 Oct 2009 19:41:29 -0400 Received: from [199.232.76.173] (port=39253 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtVH3-0007p4-Jq for qemu-devel@nongnu.org; Thu, 01 Oct 2009 19:41:25 -0400 Received: from mail2.shareable.org ([80.68.89.115]:38385) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MtVH3-0008GS-70 for qemu-devel@nongnu.org; Thu, 01 Oct 2009 19:41:25 -0400 Date: Fri, 2 Oct 2009 00:41:07 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 4/9] pci: use uint64_t for bar addr and size instead of uint32_t. Message-ID: <20091001234107.GA28250@shareable.org> References: <1247656509-32227-1-git-send-email-yamahata@valinux.co.jp> <1247656509-32227-5-git-send-email-yamahata@valinux.co.jp> <20090930114122.GG18802@redhat.com> <20090930161547.GB21595@redhat.com> <20090930172641.GA28300@redhat.com> <20091001053302.GA3317@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Isaku Yamahata , qemu-devel@nongnu.org, "Michael S. Tsirkin" 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