[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gnulib] Reusing vasnprintf
From: |
Daniel Jacobowitz |
Subject: |
Re: [bug-gnulib] Reusing vasnprintf |
Date: |
Wed, 18 Oct 2006 16:10:46 -0400 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Wed, Oct 18, 2006 at 09:44:58PM +0200, Bruno Haible wrote:
> > > How does what you need compare with the register_printf_function /
> > > parse_printf_format facility in glibc's public header file <printf.h> ?
> >
> > Wow, I knew about register_printf_function, but I'd never noticed
> > parse_printf_format before.
>
> But without the other part, which constructs the output string, this
> function is useless to gdb, right? So there's no point in gnulib trying
> to make a 100% glibc compatible parse_printf_format.
Right.
> > printf breaks down into three stages: parsing the format string,
> > recovering the arguments, and constructing the output string. We need
> > completely normal versions of the first and third, but a non-va_arg
> > based version of the second.
>
> Are you sure you can use the parsing stage and the output stage without
> modifications?
> - In the parsing phase, you need to recognize %lld also if the host
> environment
> doesn't support long longs (e.g. on MSVC hosts). This means the
> #ifdef HAVE_LONG_LONG_INT
> in printf-args.h needs to be adjusted for your use case.
Yes, it looks like you're right. And, similar changes would have to be
made to printf-parse.c. If we did this to the same copy, that would
change the behavior of "%lld" on hosts which don't support long long;
previously it would be handled as "long", and subsequently it would
lead to an error in printf_fetchargs. Is that undesirable?
> - In the output stage, when the host has 32-bit 'long's and the target
> environment has 64-bit 'long's, the output routine that converts a
> 'long' to decimal needs to be able to produce 20 decimal digits, not
> just 10.
No, I don't think I'd do it that way - it would be crazy, because it
would have to rely on a different member of the arg union to hold the
value, which would not fit otherwise.
I was figuring I'd transform the result of printf-parse.c
appropriately as I fetched the arguments. When presented with a
"%ld" conversion that wouldn't work on the host, I'd adjust the
flags to do a host "%lld" instead.
I'm now worrying that I misunderstood how the gnulib vasnprintf works,
though. This may be less useful than I thought, since it uses both the
result of arg parsing and the format string :-(
> - Also in the output stage, when you encounter a %ls directive with a
> wide string argument, to you perform the wcstombs on the host machine
> or on the target machine?
To be honest, I don't particularly care about this today. GDB support
for wide strings is miniscule and no one is improving it. However,
if I were to support it, I would try to emulate the target machine's
behavior on the host through some other mechanism.
--
Daniel Jacobowitz
CodeSourcery