Re-implement MSVCRT *printf

[Aneurin Price]

I've been meaning to do this for ages, and finally got around to it.
msvcrt.dll was using native printf functions, with some munging within 
WINE to approximate differences in how they should work in Windows. This 
caused some problems in situations not supported by glibcs *printf, for 
example, bugs 321[0] and 2075[1].
I'm not an experienced C programmer, so I don't really know if this 
implementation is any good - or even sane, but it seems to work for 
everything I've tested so far, with some caveats:
- When using "printf("%f",number)", where number is NaN, behaviour with 
the native dll seems a bit odd. The specification[2] states that the 
output should be "digit.#NANrandom-digits", whereas in actuality it 
outputs (for me) "1.#QNAN00", also it mentions "Indefinite (same as 
quiet NaN) 	digit.#INDrandom-digits", which I've simply not implemented 
as I have no idea when this would happen.
- When using "wprintf("some non-unicode string"), native wprintf detects 
that the string is non-unicode and does nothing, returning -1 - however 
I couldn't think of how to do this, so it attempts to print anyway (the 
current code also has this problem).
- There may be some other things I've not noticed, or of course some 
bugs I didn't manage to shake out :).
- ATM I have no idea what I might do for a conformance test for this, so 
if this is required I'd need someone to give me some hints.
- The patch is quite large but I don't see any way of breaking it down 
into smaller parts.
- Some bits of code in printf.c come from file.c, but I'm not really 
sure how this should be attributed.
- I'm really very *un*sure about the way I've put the main functions in 
printf.c, and then included helpers in printf.h twice (for wide 
equivalents); perhaps this is bad coding style?
- Commenting is fairly erratic; if it turns out to be (more-or-less) 
acceptable, I'll do a better job:).
- Lastly (and with any luck there's nothing else I've forgotten), I hope 
I got the patch format right...

I originally planned simply to parse format strings and edit them to the 
glibc equivalents, then pass them on, (converting between ASCII and 
unicode as appropriate) but numerous small differences meant that I'd 
have had to do lots of random editing of the strings produced, which 
seemed so unpleasant that I eventually decided to implement it from scratch.
Any comments would be appreciated, even if it's just to say "this is 
awful", since this is actually probably the majority of my C experience, 
and it would be nice to learn from my mistakes :),
Aneurin Price.

[0]http://bugs.winehq.org/show_bug.cgi?id=321
[1]http://bugs.winehq.org/show_bug.cgi?id=2075
[2]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_precision_specification.asp

Changelog:
Re-implement all *printf functions in msvcrt.dll, according to 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_format_specification_fields_.2d_.printf_and_wprintf_functions.asp
and descriptions of appropriate functions.

Modified Files:
dlls/msvcrt/Makefile.in
dlls/msvcrt/file.c
dlls/msvcrt/msvcrt.spec
dlls/msvcrt/wcs.c

Added Files:
dlls/msvcrt/printf.c
dlls/msvcrt/printf.h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: printf.diff
Type: text/x-patch
Size: 47140 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20041024/948165e6/printf.bin