On 8/1/05, Lukasz Janyst ljan@wp.pl wrote:
Hello, I've implemented 'I', 'I32' and 'I64' prefixes support for pf_vsnprintf. This patch seems to resolve profile creation issues in Warcraft 3.
Lukasz Janyst
We talked about this already. Doing it that way is not portible outside libc. I am going to take a look at this again after the 4th, actually.
Jesse
Question: Why doesnt WINE just have a complete implementation of the core "printf" logic itself? With all the differences between "printf" as defined in ANSI C and as is present on the systems WINE runs on (i.e. linux, darwin, solaris, BSD etc) and "printf" as implemented by Microsoft in their C Runtime library, it seems to me that it would make more sense to write a complete implentation of the core "printf" functionality instead of trying to make it "fit" onto whatever minimum set of functionality the target can be expected to have and hacking the rest on top of that.
Although I dont know much about the differences between printf & friends on linux, windows, solaris etc etc so I could be way off base here :)
Jonathan Wilson wrote:
Question: Why doesnt WINE just have a complete implementation of the core "printf" logic itself?
It's a little more complicated than you think, after you start handling all the width modifiers, various floating point formats, etc.
Feel free to go ahead and write one if you like :)
Mike
Feel free to go ahead and write one if you like :)
One assumes ReactOS needs such a function, how do they do it? Would getting the ReactOS guys to re-licence as LGPL (if such a thing is even possible) their printf base code work? (is what they have even any use?)
Just a thought :)
Just ask. The ReactOS team have been working closely with the Wine project; I don't see there's any problem.
Wesley Parish
On Wed, 03 Aug 2005 02:12, Jonathan Wilson wrote:
Feel free to go ahead and write one if you like :)
One assumes ReactOS needs such a function, how do they do it? Would getting the ReactOS guys to re-licence as LGPL (if such a thing is even possible) their printf base code work? (is what they have even any use?)
Just a thought :)
On Tue, Aug 02, 2005 at 10:35:59PM +0900, Mike McCormack wrote:
It's a little more complicated than you think, after you start handling all the width modifiers, various floating point formats, etc.
Not to mention coding in the 'brokenness'! On windows: _snprintf(buff, 3, "ab" ) returns 2, buff = "ab<0>" _snprintf(buff, 3, "abcd" ) returns -1, buff = "ab<0>" but: _snprintf(buff, 3, "abc" ) returns 3, buff = "abc" without NUL terminating the string.
Do you replicate that?
David
David Laight wrote:
On Tue, Aug 02, 2005 at 10:35:59PM +0900, Mike McCormack wrote:
It's a little more complicated than you think, after you start handling all the width modifiers, various floating point formats, etc.
Not to mention coding in the 'brokenness'! On windows: _snprintf(buff, 3, "ab" ) returns 2, buff = "ab<0>" _snprintf(buff, 3, "abcd" ) returns -1, buff = "ab<0>" but: _snprintf(buff, 3, "abc" ) returns 3, buff = "abc" without NUL terminating the string.
Do you replicate that?
David
I believe my attempt at this was entirely compatible with Windows' behaviour (modulo some potential undiscovered bugs), including deviations from MSDN. Unfortunately, it wasn't very well written, and I can never seem to find the time to get the experience necessary to become competent. If anyone wants to look at it though, try the archive for wine-devel and wine-patches. If anyone has a *particular* interest, I might even have a look at it again with the benefit of at least *some* additional coding practice :). At least I could reduce the number of HeapAllocs, though I imagine there are more fundamental problems... Aneurin Price