msvcrt: portable printf integer conversions

Mike McCormack mike at codeweavers.com
Mon Sep 26 22:22:13 CDT 2005


Hi Jesse,

Jesse Allen wrote:
> Here's a patch to start the work on getting our own printf number
> conversions done internally.  It adds pf_integer_conv, which is
> capable of handling d,x,o,u,i.  However, a large part of my intent is
> to add support for I64 size integers.  So I've decided to only foward
> I64 sizes to it at this time, and leave the rest intact, as I've only
> tested I64.  I sent a message to wine-devel last night for comments,
> but it seems to have gotten lost.  We need to guage how to restructure
> the printf code, especially since I've found two bugs in our current
> implementation.

Code to handle %I64 and %I32 has been missing for a while.  Thanks for 
looking into this.

Please make sure to write some test cases, as changing it will probably 
break something (or even make some of the current test cases pass).

If you look at glibc's printf code, you'll realize how messy complete 
printf handling is...  IMO, it would be better to let glibc handle the 
complexities of printf where possible, and work around the differences 
as we have done so far.

Some comments on the patch:

> +    if( flags->Format == 'X' )
> +        digits = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
> +    else
> +        digits = "0123456789abcdefghijklmnopqrstuvwxyz";

Do you really need the whole alphabet?

> +                else if( *(p+1) == '3' && *(p+2) == '2' )
> +                {
> +                    FIXME("%%I32 unhandled\n");
> +                    p += 3;
> +                }
> +                else
> +                {
> +                    FIXME("%%I unhandled\n");
> +                    p++;

Seems like if you have the code to do %I64, then doing %I32 would be 
easy too...

I think that you'll find that %I31 is invalid, but again you'll need a 
test case to make sure.

Mike



More information about the wine-devel mailing list