From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54256 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUFlQ-0004dM-IT for qemu-devel@nongnu.org; Thu, 01 Jul 2010 05:08:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUFlP-0004HR-1x for qemu-devel@nongnu.org; Thu, 01 Jul 2010 05:08:56 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:58019) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUFlO-0004Gq-ME for qemu-devel@nongnu.org; Thu, 01 Jul 2010 05:08:55 -0400 Message-ID: <4C2C5B21.50306@mail.berlios.de> Date: Thu, 01 Jul 2010 11:08:49 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/14] Add new data type for fprintf like function pointers References: <1269890225-13639-1-git-send-email-weil@mail.berlios.de> <1269890225-13639-2-git-send-email-weil@mail.berlios.de> <20100408192902.GI6056@volta.aurel32.net> <4BBF0D7B.60400@mail.berlios.de> In-Reply-To: <4BBF0D7B.60400@mail.berlios.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: QEMU Developers Am 09.04.2010 13:20, schrieb Stefan Weil: > Aurelien Jarno schrieb: >> On Mon, Mar 29, 2010 at 09:16:52PM +0200, Stefan Weil wrote: >>> The compiler should check the arguments for these functions. >>> >>> gcc can do this, but only if the function pointer's prototype >>> includes the __attribute__ flag. >>> >>> As the necessary declaration is a bit lengthy, we use a new >>> data type 'fprintf_function'. >>> >>> It is not easy to find a single header file which is included >>> everywhere, so fprint_function had to be declared in several >>> header files. >> >> I don't really think it is a good idea to duplicate that. It will only >> causes problem in the future. Are you sure there is no header for that? >> Worst case scenario it's probably better to create a new header. > > I had no better idea. As long as the duplicate declarations > always observe the same pattern, they should not really cause > problems. Anybody who knows this pattern (which is also quite > common in system include files) will know that there are duplicates. > > I did not want to create a new header because it is really a worst > case scenario with several disadvantages. > > In the meantime I noticed that dis-asm.h also uses fprintf like > function pointers, so there is one more header which needs > the same declaration. > > Maybe the best solution would be using qemu-common.h in > cpu-exec.c, *-dis.c, */translate.c, and more files. > That would involve a lot of modifications, for example > removing code which re-implements parts of stdio.h in > dyngen-exec.h. Some restrictions why qemu-common.h was > not used might be no longer valid (I think they came > from pre-tcg times). Nevertheless, cris-dis.c even says > that it cannot include qemu-common.h (without giving a > reason). Reordering include statements or adding new > includes can have unwanted side effects which are > difficult to detect. > > So this last solution needs a lot of discussion and time. > That's the reason why I did not choose it. Maybe I was wrong > and more developers want to clean up includes, so it can be done. More files use qemu-common.h now, so it seems possible to declare the new data type only once (in qemu-common.h). There are undetected format errors in current code. Without argument checking by the compiler, even new format errors are introduced from time to time. Therefore the motivation for these patches is still given. Before I send updated patches, I'd like to ask a simple question: There is already a data type named 'fprintf_type' (without __attribute__ flag) which is only used in *-dis.c. So which name is preferred for the new data type with __attribute__ flag? * fprintf_type (already used in *-dis.c)? * fprintf_function (which I used in my patches) * any other name (coding rules?)