Descrepancy between Windows and GLIBC version of [v]snprintf

[Daniel Gehriger]

Hi,

I found a problem with the _snprintf() / _vsnprintf() functions. Wine seems
to use the forward these function calls to their native implementation (eg.
in GLIBC). The problem is that they behave differently under Windows and
GLIBC:

Both function take a parameter to specify the maximum number of characters
to write. Under Windows, if the formated string is equal in length to or
exceeds the specified number, the terminating NULL will NOT be written to
the buffer. Under Linux, the terminating NULL is ALWAYS written.

The test program below produces the following output (only when linked
dynamically, of course) :

Under Windows: 			0000000001****
Under Wine:    			000000000
When compiled on Linux:		000000000

---------------------------------------------------------
#include <stdio.h>
#include <memory.h>

int main()
{
  char buffer[16];
  memset(buffer, 0, 16);
  memset(buffer, '*', 15);

  int len = _snprintf(buffer, 10, "%010d", 1);  
  
  printf("%d : %s\n", len, buffer);
  
  return 0;
}
---------------------------------------------------------

Regards,

Daniel

[Uwe Bonnes]

> > > > > "Daniel" == Daniel Gehriger <gehriger(a)linkcad.com> writes:

Daniel> Hi, I found a problem with the _snprintf() / _vsnprintf()
    Daniel> Under Windows: 0000000001**** Under Wine: 000000000 When
    Daniel> compiled on Linux: 000000000

There are more such subtile discrepancies. Only when applications rely on
that, wine should be fixed. Consider rewriting your test for the wine
regression test suite, comment it with the problem showing that problem and
send a patch.

Bye
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Daniel Gehriger]

> -----Original Message-----
> From: Uwe Bonnes [mailto:bon(a)elektron.ikp.physik.tu-darmstadt.de] 
> Sent: Wednesday, November 26, 2003 6:46 PM
> > > > > > "Daniel" == Daniel Gehriger <gehriger(a)linkcad.com> writes:
>
> Daniel> Hi, I found a problem with the _snprintf() / _vsnprintf()
>     Daniel> Under Windows: 0000000001**** Under Wine: 000000000 When
>     Daniel> compiled on Linux: 000000000
>
> There are more such subtile discrepancies. Only when 
> applications rely on
> that, wine should be fixed. Consider rewriting your test for the wine
> regression test suite, comment it with the problem showing 
> that problem and
> send a patch.

The symstore.exe tool from the Debugging Tools for Windows fails due to this
error. For now, I patched the symstore.exe to make it work. 

I'm not familiar with how the Wine source code is laid out. The solution
would be not to forward these calls to the native library, but provide a
custom implementation, just like the wide-character variants. I can do that,
but I wouldn't know where exactly to add it (user.dll ? msvcrt.dll ? ... ?).

I can write a regression test, though.

Regards,

Daniel

[Ferenc Wagner]

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
> > > > > > "Daniel" == Daniel Gehriger <gehriger(a)linkcad.com> writes:
>
> Daniel> Hi, I found a problem with the _snprintf() / _vsnprintf()
>     Daniel> Under Windows: 0000000001**** Under Wine: 000000000 When
>     Daniel> compiled on Linux: 000000000
>
> There are more such subtile discrepancies. Only when
> applications rely on that, wine should be fixed. Consider
> rewriting your test for the wine regression test suite,
> comment it with the problem showing that problem and send
> a patch.

I did this already (New snprintf test, sent to wine-patches
on 31 Oct), but my patch never got submitted.  It may be a
good starting point at least.

Feri.