Hi,
Here I have filed a bug on vsnprintf: http://bugs.winehq.org/show_bug.cgi?id=2075
Basically it says, without repeating, that vsnprintf called from glibc is not quite a suitable replacement for an actual msvcrt vsnprintf. An example is given to highlight a specific issue. I have a question on how should one approach fixing this? I have thought of two different ways:
1) Create our own vsnprintf version from scratch (fairly difficult) or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance.
The issue intrigues me, and I find that it should be resolved at some point. I'd like to get on the right path, so I'd at least start on something that will later be accepted.
Thanks, Jesse
On Sun, 07 Mar 2004 19:32:39 -0700, Jesse Allen wrote:
- Create our own vsnprintf version from scratch (fairly difficult)
or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance.
3) Copy/paste the glibc version into Wine with appropriate munging and start fixing bugs in it.
No clue which is best. Alexandre?
"Mike" == Mike Hearn mh@codeweavers.com writes:
Mike> On Sun, 07 Mar 2004 19:32:39 -0700, Jesse Allen wrote: >> 1) Create our own vsnprintf version from scratch (fairly difficult) >> or 2) Create a wrapper for glibc's vsnprintf that translates win32ish >> format statements into a glibc friendly one. (not too bad and >> smaller patch) We could later move in a better or complete version to >> improve performance.
Mike> 3) Copy/paste the glibc version into Wine with appropriate munging Mike> and start fixing bugs in it.
Another option is to extend the glibcv version and try to get that version into glibc...
On Mon, 08 Mar 2004 11:59:55 +0100, Uwe Bonnes wrote:
Another option is to extend the glibcv version and try to get that version into glibc...
a) It's not portable to non-glibc systems then b) I take it you never tried to get patches into glibc before ;)
I mean if you think you can convince Ulrich Drepper to include non-POSIX win32 compatibility cruft into glibc by all means go ahead, but you won't catch me trying :)
thanks -mike
Mike Hearn mh@codeweavers.com writes:
On Sun, 07 Mar 2004 19:32:39 -0700, Jesse Allen wrote:
- Create our own vsnprintf version from scratch (fairly difficult)
or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance.
- Copy/paste the glibc version into Wine with appropriate munging and
start fixing bugs in it.
No clue which is best. Alexandre?
Probably 3), but I don't think you want to start with the glibc code, it's fairly ugly code, with many dependencies on glibc internals and gcc-specific things. Hopefully we can find a more portable implementation somewhere else.
On March 8, 2004 10:15 am, Alexandre Julliard wrote:
Mike Hearn mh@codeweavers.com writes:
On Sun, 07 Mar 2004 19:32:39 -0700, Jesse Allen wrote:
- Create our own vsnprintf version from scratch (fairly difficult)
or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance.
- Copy/paste the glibc version into Wine with appropriate munging and
start fixing bugs in it.
No clue which is best. Alexandre?
Probably 3), but I don't think you want to start with the glibc code, it's fairly ugly code, with many dependencies on glibc internals and gcc-specific things. Hopefully we can find a more portable implementation somewhere else.
Just to complicate things there is also the complication that (at least on my system) the Windows version has an off-by-1 bug. (msvcrt 6.1.9844 - snprintf (buffer, 4, "%d", 4321) writes 4321, returns 4 and does not add the \0)
On March 8, 2004 10:54 am, Bill Medland wrote:
On March 8, 2004 10:15 am, Alexandre Julliard wrote:
Mike Hearn mh@codeweavers.com writes:
On Sun, 07 Mar 2004 19:32:39 -0700, Jesse Allen wrote:
- Create our own vsnprintf version from scratch (fairly difficult)
or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance.
- Copy/paste the glibc version into Wine with appropriate munging and
start fixing bugs in it.
No clue which is best. Alexandre?
Probably 3), but I don't think you want to start with the glibc code, it's fairly ugly code, with many dependencies on glibc internals and gcc-specific things. Hopefully we can find a more portable implementation somewhere else.
Just to complicate things there is also the complication that (at least on my system) the Windows version has an off-by-1 bug. (msvcrt 6.1.9844 - snprintf (buffer, 4, "%d", 4321) writes 4321, returns 4 and does not add the \0)
Woops - my mistake. Actually it is the difference between the Windows definition and the POSIX definiton (and I can't be bothered looking up the exact details of the old (SUS V2?) one). Anyway, no matter how we look at it the return behaviour needs munging.
On Mon, Mar 08, 2004 at 10:15:33AM -0800, Alexandre Julliard wrote:
Probably 3), but I don't think you want to start with the glibc code, it's fairly ugly code, with many dependencies on glibc internals and gcc-specific things. Hopefully we can find a more portable implementation somewhere else.
Ethereal brings its own version of (v)snprintf in form of the snprintf.[hc] files. While Ethereal is GPLed, the files in question are LGPLed. The files do not originate with Ethereal but I don't remember where they came from.
Ciao Jörg
On Mon, Mar 08, 2004 at 08:28:38PM +0100, Joerg Mayer wrote:
Ethereal brings its own version of (v)snprintf in form of the snprintf.[hc] files. While Ethereal is GPLed, the files in question are LGPLed. The files do not originate with Ethereal but I don't remember where they came from.
I have looked at this version and have been able to adapt it for msvcrt. I've found it fairly easy to work with. I've even added I, I32, and I64, I think. Discovered an issue with null pointer passed for %s (Warcraft III likes to do that it seems). I handle it by printing "(null)". Other than that, it will require some cleaning up, and still some testing. I've put it on ftp://narf.dnip.net/vsnprintf/ for anyone to take a look at it now. At this point, I don't know of any functionality issues (maybe some more null pointer handling?)
Jesse
On Mon, Mar 08, 2004 at 10:48:31AM +0000, Mike Hearn wrote:
On Sun, 07 Mar 2004 19:32:39 -0700, Jesse Allen wrote:
- Create our own vsnprintf version from scratch (fairly difficult)
or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance.
- Copy/paste the glibc version into Wine with appropriate munging and
start fixing bugs in it.
No clue which is best. Alexandre?
Newlib has vsnprintf and is BSD-licensed. This might be more convenient for inclusion into WINE.
newlib/newlib/libc/stdio/vsnprintf.c
-
Alexandre Julliard -
Bill Medland -
Jesse Allen -
Joerg Mayer -
Mike Hearn -
Ryan Underwood -
Uwe Bonnes