Printf Integer Conversions update

[Jesse Allen]

Hi All,

I've updated my patch and need comments on it.  The patch is for a
portible method for integer conversions in printf.  Since it's
primarily intended for I64 sizes that it is all it is used for to
avoid breaking anything else, even though, it should be able to handle
all integers.

You can find it at http://www.chez.com/alors/
along with lots of tests.

Since last time, I was wondering what to do about %I64e, and well,
testing it out it seems to be just like %e on windows so I decided to
not worry about our own float I64 conversion since it's the same.  So
only I64 integer types get fowarded to pf_integer_conv and floats just
get put through libc's printf.  I still wonder about %I64e versus %e
just because libc's %lle and %e are different hmmmm.

This time I use pf_output_format_A to handle the field output.  I had
to modify it to account for the extra sign and alternate formatting. 
I guess I need to modify pf_output_format_W the same way, but some one
let me know if it is needed and whether just copying what I have over
is ok.

I added pf_is_integer_format to detect when I have an integer and I64
size case.  I modified the others so each uppercase and lowercase type
is explicit:
 static inline BOOL pf_is_valid_format( char fmt )
 {
-    char float_fmts[] = "acdefginoux";
+    char float_fmts[] = "acCdeEfgGinouxX";
     if (!fmt)
         return FALSE;
-    fmt = tolower( fmt );
     return strchr( float_fmts, fmt ) ? TRUE : FALSE;
 }

Because D is not a valid conversion type, and especially 'I'.  If we
get passed %I0d for example, it should print I0d.  If I didn't do
this, then it tries to convert 'I' as an 'i' type, which would be a
bug.  I don't know if this will cause other things to regress, so I
could back out the change.

In my testing of I64 on windows 2k3 (x86), I hit an obscure bug?
'%#+25.22I64u' for -1 prints ' 18446744073709551615' returning 21  but
normally it should be
'   0018446744073709551615' returning 25.  It only does it only for
I64 types, and only in this exact combination -- precision and field
doesn't matter what number, but #+ must be there and be unsigned.  If
I try '%+#25.22I64u' then I get correct output.  You can see this in
the tests and try it out.  I tried about 20-30 other combinations and
it only happens this way.  I haven't built in support of the bug yet,
but it is there.  So I'm thinking, great, we have to support this
obscure I64 with bugs too.

Jesse