bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]