qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Weil <weil@mail.berlios.de>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 01/14] Add new data type for fprintf like function pointers
Date: Fri, 09 Apr 2010 13:20:27 +0200	[thread overview]
Message-ID: <4BBF0D7B.60400@mail.berlios.de> (raw)
In-Reply-To: <20100408192902.GI6056@volta.aurel32.net>

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.

>
>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>> ---
>> cpu-all.h | 13 +++++++++----
>> cpu-defs.h | 6 ++++++
>> qemu-common.h | 6 ++++++
>> 3 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/cpu-all.h b/cpu-all.h
>> index f281a91..d5c1380 100644
>> --- a/cpu-all.h
>> +++ b/cpu-all.h
>> @@ -760,11 +760,17 @@ void cpu_exec_init_all(unsigned long tb_size);
>> CPUState *cpu_copy(CPUState *env);
>> CPUState *qemu_get_cpu(int cpu);
>>
>> +#if !defined(FPRINTF_FUNCTION_DEFINED)
>> +#define FPRINTF_FUNCTION_DEFINED
>> +typedef int (*fprintf_function)(FILE *f, const char *fmt, ...)
>> + __attribute__ ((format(printf, 2, 3)));
>> +#endif
>> +
>> void cpu_dump_state(CPUState *env, FILE *f,
>> - int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
>> + fprintf_function cpu_fprintf,
>> int flags);
>> void cpu_dump_statistics (CPUState *env, FILE *f,
>> - int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
>> + fprintf_function cpu_fprintf,
>> int flags);
>>
>> void QEMU_NORETURN cpu_abort(CPUState *env, const char *fmt, ...)
>> @@ -915,8 +921,7 @@ int cpu_physical_memory_get_dirty_tracking(void);
>> int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
>> target_phys_addr_t end_addr);
>>
>> -void dump_exec_info(FILE *f,
>> - int (*cpu_fprintf)(FILE *f, const char *fmt, ...));
>> +void dump_exec_info(FILE *f, fprintf_function cpu_fprintf);
>> #endif /* !CONFIG_USER_ONLY */
>>
>> int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
>> diff --git a/cpu-defs.h b/cpu-defs.h
>> index 2e94585..81edf87 100644
>> --- a/cpu-defs.h
>> +++ b/cpu-defs.h
>> @@ -72,6 +72,12 @@ typedef uint64_t target_ulong;
>> #define TB_JMP_ADDR_MASK (TB_JMP_PAGE_SIZE - 1)
>> #define TB_JMP_PAGE_MASK (TB_JMP_CACHE_SIZE - TB_JMP_PAGE_SIZE)
>>
>> +#if !defined(FPRINTF_FUNCTION_DEFINED)
>> +#define FPRINTF_FUNCTION_DEFINED
>> +typedef int (*fprintf_function)(FILE *f, const char *fmt, ...)
>> + __attribute__ ((format(printf, 2, 3)));
>> +#endif
>> +
>> #if !defined(CONFIG_USER_ONLY)
>> #define CPU_TLB_BITS 8
>> #define CPU_TLB_SIZE (1 << CPU_TLB_BITS)
>> diff --git a/qemu-common.h b/qemu-common.h
>> index 087c034..3658bfe 100644
>> --- a/qemu-common.h
>> +++ b/qemu-common.h
>> @@ -91,6 +91,12 @@ static inline char *realpath(const char *path,
>> char *resolved_path)
>>
>> #else
>>
>> +#if !defined(FPRINTF_FUNCTION_DEFINED)
>> +#define FPRINTF_FUNCTION_DEFINED
>> +typedef int (*fprintf_function)(FILE *f, const char *fmt, ...)
>> + __attribute__ ((format(printf, 2, 3)));
>> +#endif
>> +
>> #include "cpu.h"
>>
>> #endif /* !defined(NEED_CPU_H) */
>> -- 
>> 1.7.0
>>
>>
>>
>>
>

  reply	other threads:[~2010-04-09 11:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 19:16 [Qemu-devel] Check format specifiers for fprintf like function pointers Stefan Weil
2010-03-29 19:16 ` [Qemu-devel] [PATCH 01/14] Add new data type " Stefan Weil
2010-04-08 19:29   ` Aurelien Jarno
2010-04-09 11:20     ` Stefan Weil [this message]
2010-07-01  9:08       ` Stefan Weil
2010-07-01 23:08         ` Aurelien Jarno
2010-07-02 15:37       ` [Qemu-devel] " Paolo Bonzini
2010-07-02 16:17         ` [Qemu-devel] [RFC] env stored in segment register for i386 Richard Henderson
2010-07-03  7:32         ` [Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like function pointers Blue Swirl
2010-03-29 19:16 ` [Qemu-devel] [PATCH 02/14] Use fprint_function and fix wrong format specifiers Stefan Weil
2010-03-29 19:16 ` [Qemu-devel] [PATCH 03/14] target-alpha: Use fprintf_function Stefan Weil
2010-03-29 19:16 ` [Qemu-devel] [PATCH 04/14] target-arm: " Stefan Weil
2010-03-29 19:16 ` [Qemu-devel] [PATCH 05/14] target-cris: " Stefan Weil
2010-03-29 19:16 ` [Qemu-devel] [PATCH 06/14] target-i386: Use fprintf_function and fix dump of DR registers Stefan Weil
2010-03-29 19:16 ` [Qemu-devel] [PATCH 07/14] target-m68k: Use fprintf_function Stefan Weil
2010-03-29 19:16 ` [Qemu-devel] [PATCH 08/14] target-microblaze: " Stefan Weil
2010-03-29 19:17 ` [Qemu-devel] [PATCH 09/14] target-mips: Use fprintf_function and fix wrong format specifiers Stefan Weil
2010-04-01 21:05   ` [Qemu-devel] [PATCH] target-mips: Fix format specifiers for fpu_fprintf Stefan Weil
2010-04-09 19:54     ` Aurelien Jarno
2010-03-29 19:17 ` [Qemu-devel] [PATCH 10/14] target-ppc: Use fprintf_function and fix wrong format specifiers Stefan Weil
2010-03-29 19:17 ` [Qemu-devel] [PATCH 11/14] target-sh4: Use fprintf_function Stefan Weil
2010-03-29 19:17 ` [Qemu-devel] [PATCH 12/14] target-sparc: " Stefan Weil
2010-03-29 19:17 ` [Qemu-devel] [PATCH 13/14] target-s390: " Stefan Weil
2010-03-29 19:17 ` [Qemu-devel] [PATCH 14/14] tcg: " Stefan Weil
2010-03-29 19:27 ` [Qemu-devel] Check format specifiers for fprintf like function pointers Stefan Weil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BBF0D7B.60400@mail.berlios.de \
    --to=weil@mail.berlios.de \
    --cc=aurelien@aurel32.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).