bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw
       [not found]   ` <BANLkTikdXpuNaA+Xc1GOCKOOtbegd83o0w@mail.gmail.com>
@ 2011-07-01 13:06     ` Eric Blake
  2011-07-01 13:50       ` Eric Blake
  0 siblings, 1 reply; 7+ messages in thread
From: Eric Blake @ 2011-07-01 13:06 UTC (permalink / raw
  To: Matthias Bolte; +Cc: libvir-list, bug-gnu-libiconv, bug-gnulib

[-- Attachment #1: Type: text/plain, Size: 4445 bytes --]

[adding bug-gnulib, bug-gnu-libiconv]

On 07/01/2011 04:50 AM, Matthias Bolte wrote:
> 2011/6/30 Eric Blake <eblake@redhat.com>:
>> On 06/30/2011 12:00 PM, Eric Blake wrote:
>>> Gnulib documents that mingw [v]snprintf is broken (it returns -1
>>> on out-of-space, instead of the count of what would have been
>>> printed); but while we were using the snprintf wrapper, we had
>>> not yet been using the vsnprintf wrapper.
>>>
>>> * bootstrap.conf (gnulib_modules): Add vsnprintf.
>>> Reported by Matthias Bolte.
>>> ---
>>>  bootstrap.conf |    1 +
>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> Followup.  There are two forks of mingw - the older mingw project is
>> 32-bit only, and has added wrappers into their w32api libraries that
>> substitute the broken [v]snprintf of msvcrt with a mingw-specific one
>> that is POSIX-compliant out of the box.  Then there is the mingw64
>> project, which can compile for both 32-bit and 64-bit, and where their
>> w32api libraries do not yet override [v]snprintf.  [For reference,
>> Fedora 15 uses the older mingw project, but Fedora 16 is hoping to
>> switch to the newer mingw64 project; meanwhile, cygwin ships with
>> cross-compilers for both flavors, which is how I tested the vsnprintf
>> behavior of both flavors]
>>
>> The gnulib documentation tends to lag various mingw fixes, and (to date)
>> has not been making any distinction between the mingw and mingw64 projects.
>>
>> This patch will help mingw64, so it is worth applying.  However,
>> Matthias and I spent some time on IRC and we are quite confused at why
>> his mingw build is having issues - since mingw uses wrappers that work
>> and do not need the gnulib replacement in the first place, at least at
>> configure time, this change to bootstrap.conf did not change anything
>> for his build.  I'm wondering if maybe libtools attempts to directly
>> invoke ld instead of going through gcc as the linker are causing
>> problems, where the configure test used gcc and sees the working wrapper
>> vsnprintf, but then virsh is compiled via libtool and ends up using the
>> native broken vsnprintf.  At least, that's all I was able to guess :(
> 
> Simple tests show that [v]snprintf works correctly with mingw (I
> didn't test mingw64) in case of a too small buffer. It's only broken
> in the context of libvirt. I finally figured out that libintl is the
> cause for this, as Eric already suggested as a possible cause on IRC.
> It's not related to libtool at all.
> 
> libintl.h is included by gnulib's gettext.h, that is included by
> internal.h, that is included by buf.h, that is included by buf.c. This
> it how we get it there to break in libvirt, because libintl.h (from
> http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/gettext-runtime-dev_0.18.1.1-2_win32.zip)
> contains this section
> 
> #if 1
> 
> #if !(defined snprintf && defined _GL_STDIO_H) /* don't override gnulib */
> #undef snprintf
> #define snprintf libintl_snprintf
> extern int snprintf (char *, size_t, const char *, ...);
> #endif
> #if !(defined vsnprintf && defined _GL_STDIO_H) /* don't override gnulib */
> #undef vsnprintf
> #define vsnprintf libintl_vsnprintf
> extern int vsnprintf (char *, size_t, const char *, va_list);
> #endif
> 
> #endif
> 
> gnulib's stdio.h is included prior to the inclusion of libintl.h so
> _GL_STDIO_H is defined, but gnulib detected that it doesn't need to
> replace [v]snprintf, therefore [v]snprintf isn't defined and both
> #if's are true and libintl.h replaces [v]snprintf with it's own broken
> version. I can reproduce the problem in a test program by including
> said libintl.h.
> 

Why is libintl's [v]snprintf broken on mingw?  Even if libintl is
compiled against an older mingw where there is no mingw snprintf
replacement, it seems like libintl should be honoring the correct return
values.

And what can gnulib do to work around the case where mingw has fixed
snprintf, but libintl still has broken snprintf, and thus the gnulib
headers did not define snprintf?  Should the gnulib <stdio.h>
replacement _always_ define snprintf, even if only by:

#define snprintf snprintf

so that inclusion of the gnulib header prior to the libintl headers
forces libintl to leave well enough alone?

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw
  2011-07-01 13:06     ` [libvirt] [PATCH] build: fix virBufferVasprintf on mingw Eric Blake
@ 2011-07-01 13:50       ` Eric Blake
  2011-07-01 16:13         ` Eric Blake
  2011-07-01 16:27         ` [PATCH] snprintf: guarantee %1$d, for libintl Eric Blake
  0 siblings, 2 replies; 7+ messages in thread
From: Eric Blake @ 2011-07-01 13:50 UTC (permalink / raw
  Cc: libvir-list, bug-gnu-libiconv, bug-gnulib, Matthias Bolte

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

On 07/01/2011 07:06 AM, Eric Blake wrote:
> Why is libintl's [v]snprintf broken on mingw?  Even if libintl is
> compiled against an older mingw where there is no mingw snprintf
> replacement, it seems like libintl should be honoring the correct return
> values.

It is because libintl on mingw is specifically using _vsnprintf (the
broken msvcrt version) rather than vsnprintf (the fixed mingw override):
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/printf.c#n195

in order to fix the fact that both Microsoft and mingw's override do not
understand %1$d, but libintl must support argument reordering.

> 
> And what can gnulib do to work around the case where mingw has fixed
> snprintf, but libintl still has broken snprintf, and thus the gnulib
> headers did not define snprintf?  Should the gnulib <stdio.h>
> replacement _always_ define snprintf, even if only by:
> 
> #define snprintf snprintf
> 
> so that inclusion of the gnulib header prior to the libintl headers
> forces libintl to leave well enough alone?

But now we have a problem - if gnulib did _not_ replace snprintf because
it probed the mingw version and found that the return value was correct,
then the libintl override violates gnulib's assumptions.  If gnulib
_does_ replace snprintf, but does not support %1$d, then gnulib violates
libintl's assumptions.  So it sounds like the LGPLv2+ gnulib modules
[v]snprintf need to guarantee %1$d parsing, since libvirt is not in a
position to upgrade to the LGPLv3+ gnulib modules [v]snprintf-posix.
And since mingw's replacement snprintf does not (currently) support
%1$d, then we will be back in the scenario of gnulib always replacing
snprintf on mingw, avoiding the fact that libintl_snprintf defers to the
broken Microsoft _snprintf.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw
  2011-07-01 13:50       ` Eric Blake
@ 2011-07-01 16:13         ` Eric Blake
  2011-07-01 16:27         ` [PATCH] snprintf: guarantee %1$d, for libintl Eric Blake
  1 sibling, 0 replies; 7+ messages in thread
From: Eric Blake @ 2011-07-01 16:13 UTC (permalink / raw
  Cc: libvir-list, bug-gnu-libiconv, bug-gnulib

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On 07/01/2011 07:50 AM, Eric Blake wrote:
> But now we have a problem - if gnulib did _not_ replace snprintf because
> it probed the mingw version and found that the return value was correct,
> then the libintl override violates gnulib's assumptions.  If gnulib
> _does_ replace snprintf, but does not support %1$d, then gnulib violates
> libintl's assumptions.

One bit of good news - I confirmed (by modifying test-vsnprintf, then
testing on mingw64, where the gnulib replacement _does_ kick in) that
gnulib's vsnprintf replacement supports %1$d out of the box without any
further m4 tests, and without having to drag in the vsnprintf-posix
module.  So at this point, the patch for mingw is as simple as ensuring
that the gnulib snprintf replacement always kicks in.  Proposed patch
coming up soon.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH] snprintf: guarantee %1$d, for libintl
  2011-07-01 13:50       ` Eric Blake
  2011-07-01 16:13         ` Eric Blake
@ 2011-07-01 16:27         ` Eric Blake
  2011-07-04  0:39           ` Bruno Haible
  1 sibling, 1 reply; 7+ messages in thread
From: Eric Blake @ 2011-07-01 16:27 UTC (permalink / raw
  To: bug-gnulib; +Cc: matthias.bolte

Newer mingw (but not yet mingw64) provides two flavors of
snprintf: _snprintf defers straight to msvcrt, which has broken
return value and does not understand %llu or %zu; and snprintf,
which fixes these two bugs but does not understand %1$s.

Libintl specifically favors _snprintf, with broken return value,
even when compiled on mingw with a fixed snprintf, because the
only behavior which it wants to fix is %1$s handling.  But this
means that the replacement libintl_snprintf has a broken return.

If one uses the 'snprintf-posix' module, then the gnulib
replacement kicks in, and does everything that libintl needs, so
on mingw, <libintl.h> specifically avoids overriding snprintf if
it detected that gnulib replaced snprintf.  However, if one only
uses the 'snprintf' module and also uses libintl, this means
there are two problems:

1. The gnulib 'snprintf' module does not replace the mingw
snprintf function, because it has proper return values, while the
libintl.h header knows that %1$d is broken so snprintf must be
replaced, with the end result that the application gets the
libintl replacement snprintf with broken return values in spite
of the gnulib module.

2. Conversely, if the application did '#define snprintf snprintf',
that would be enough to make libintl avoid installing its own
replacement because libintl would see the define as a sign that
gnulib is happy with snprintf.  However, because gnulib didn't
enforce %1$s, users can end up with translated strings that break
when passed to the native snprintf.

Happily, the gnulib snprintf replacement already guarantees %1$s
without needing any further preprocessor macros defined, and
without dragging in the LGPLv3+ bulk of snprintf-posix, so the
problem boils down to guaranteeing that gnulib will replace
snprintf if it lacks %1$s support.  Basically, gnulib must
replace snprintf under all the same conditions as libintl, as
well as any other conditions of its own, if the libintl trick
of deferring to gnulib is to work correctly.

* m4/snprintf.m4 (gl_FUNC_SNPRINTF): Require %1$d support.
* m4/vsnprintf.m4 (gl_FUNC_VSNPRINTF): Likewise.
* doc/posix-functions/snprintf.texi (snprintf): Update.
* doc/posix-functions/vsnprintf.texi (vsnprintf): Likewise.
* tests/test-snprintf.c (main): Enhance test.
* tests/test-vsnprintf.c (main): Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
---

I tested the following scenarios:

changes to tests only (no m4 changes):
Linux and Cygwin passed the new tests with no modification (no
  replacement function needed)
cross-compiling from cygwin to mingw and mingw64 passed (since
  cross-compilation is pessimistic and replaced snprintf)
native compilation on mingw64 passed (since mingw64 does not
  have a working snprintf return value)
native compilation on mingw failed (since the mingw snprintf
  does not honor %1$s)

complete patch:
Linux and Cygwin continue to pass
cross-compilation to mingw and mingw64 still passes
native compilation on mingw64 still passes
native compilation on mingw now passes (the changed m4 macro
  was enough to force the gnulib replacement)

 ChangeLog                          |   10 ++++++++++
 doc/posix-functions/snprintf.texi  |   17 +++++++----------
 doc/posix-functions/vsnprintf.texi |   17 +++++++----------
 m4/snprintf.m4                     |    9 +++++++--
 m4/vsnprintf.m4                    |    9 +++++++--
 tests/test-snprintf.c              |    8 ++++++++
 tests/test-vsnprintf.c             |    8 ++++++++
 7 files changed, 54 insertions(+), 24 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fcc2e6e..5f3ffb7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2011-07-01  Eric Blake  <eblake@redhat.com>
+
+	snprintf: guarantee %1$d, for libintl
+	* m4/snprintf.m4 (gl_FUNC_SNPRINTF): Require %1$d support.
+	* m4/vsnprintf.m4 (gl_FUNC_VSNPRINTF): Likewise.
+	* doc/posix-functions/snprintf.texi (snprintf): Update.
+	* doc/posix-functions/vsnprintf.texi (vsnprintf): Likewise.
+	* tests/test-snprintf.c (main): Enhance test.
+	* tests/test-vsnprintf.c (main): Likewise.
+
 2011-06-30  Paul Eggert  <eggert@cs.ucla.edu>

 	xnanosleep: Rewrite to use new dtotimespec module.
diff --git a/doc/posix-functions/snprintf.texi b/doc/posix-functions/snprintf.texi
index d295cea..4e7a294 100644
--- a/doc/posix-functions/snprintf.texi
+++ b/doc/posix-functions/snprintf.texi
@@ -12,12 +12,17 @@ snprintf
 This function is missing on some platforms:
 IRIX 5.3, OSF/1 4.0, Solaris 2.5.1.
 @item
-This function does not return a byte count as specified in C99 on some platforms:
+This function does not support format directives that access arguments in an
+arbitrary order, such as @code{"%2$s"}, on some platforms:
+NetBSD 3.0, mingw, BeOS.
+@item
+This function does not return a byte count as specified in C99 on some
+platforms:
 HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, mingw.
 @item
 This function overwrites memory even when a size argument of 1 is passed on some
 platforms:
-Linux libc5.
+Linux libc5, BeOS.
 @end itemize

 Portability problems fixed by Gnulib module @code{snprintf-posix}:
@@ -50,10 +55,6 @@ snprintf
 on some platforms:
 Solaris 11 2010-11.
 @item
-This function does not support format directives that access arguments in an
-arbitrary order, such as @code{"%2$s"}, on some platforms:
-NetBSD 3.0, mingw, BeOS.
-@item
 This function doesn't support the @code{'} flag on some platforms:
 NetBSD 3.0, Cygwin 1.5.24, mingw.
 @item
@@ -83,10 +84,6 @@ snprintf
 This function does not fully support the @samp{n} directive on some platforms:
 HP-UX 11, mingw.
 @item
-This function overwrites memory when a size = 1 argument is passed on some
-platforms:
-BeOS.
-@item
 This function overwrites memory even when a zero size argument is passed on some
 platforms:
 OSF/1 5.1.
diff --git a/doc/posix-functions/vsnprintf.texi b/doc/posix-functions/vsnprintf.texi
index e391f35..ca6e092 100644
--- a/doc/posix-functions/vsnprintf.texi
+++ b/doc/posix-functions/vsnprintf.texi
@@ -12,11 +12,16 @@ vsnprintf
 This function is missing on some platforms:
 IRIX 5.3, OSF/1 4.0, Solaris 2.5.1.
 @item
+This function does not support format directives that access arguments in an
+arbitrary order, such as @code{"%2$s"}, on some platforms:
+NetBSD 3.0, mingw, BeOS.
+@item
 This function overwrites memory even when a size argument of 1 is passed on some
 platforms:
-Linux libc5.
+Linux libc5, BeOS.
 @item
-This function does not return a byte count as specified in C99 on some platforms:
+This function does not return a byte count as specified in C99 on some
+platforms:
 HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, mingw.
 @end itemize

@@ -50,10 +55,6 @@ vsnprintf
 on some platforms:
 Solaris 11 2010-11.
 @item
-This function does not support format directives that access arguments in an
-arbitrary order, such as @code{"%2$s"}, on some platforms:
-NetBSD 3.0, mingw, BeOS.
-@item
 This function doesn't support the @code{'} flag on some platforms:
 NetBSD 3.0, Cygwin 1.5.24, mingw.
 @item
@@ -83,10 +84,6 @@ vsnprintf
 This function does not fully support the @samp{n} directive on some platforms:
 HP-UX 11, mingw.
 @item
-This function overwrites memory when a size = 1 argument is passed on some
-platforms:
-BeOS.
-@item
 This function overwrites memory even when a zero size argument is passed on some
 platforms:
 HP-UX 11, OSF/1 5.1.
diff --git a/m4/snprintf.m4 b/m4/snprintf.m4
index 8aa5dbe..11c7752 100644
--- a/m4/snprintf.m4
+++ b/m4/snprintf.m4
@@ -1,4 +1,4 @@
-# snprintf.m4 serial 5
+# snprintf.m4 serial 6
 dnl Copyright (C) 2002-2004, 2007-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -16,7 +16,12 @@ AC_DEFUN([gl_FUNC_SNPRINTF],
         gl_SNPRINTF_RETVAL_C99
         case "$gl_cv_func_snprintf_retval_c99" in
           *yes)
-            gl_cv_func_snprintf_usable=yes
+            gl_PRINTF_POSITIONS
+            case "$gl_cv_func_printf_positions" in
+              *yes)
+                gl_cv_func_snprintf_usable=yes
+                ;;
+            esac
             ;;
         esac
         ;;
diff --git a/m4/vsnprintf.m4 b/m4/vsnprintf.m4
index e4725e4..809c72d 100644
--- a/m4/vsnprintf.m4
+++ b/m4/vsnprintf.m4
@@ -1,4 +1,4 @@
-# vsnprintf.m4 serial 5
+# vsnprintf.m4 serial 6
 dnl Copyright (C) 2002-2004, 2007-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -16,7 +16,12 @@ AC_DEFUN([gl_FUNC_VSNPRINTF],
         gl_SNPRINTF_RETVAL_C99
         case "$gl_cv_func_snprintf_retval_c99" in
           *yes)
-            gl_cv_func_vsnprintf_usable=yes
+            gl_PRINTF_POSITIONS
+            case "$gl_cv_func_printf_positions" in
+              *yes)
+                gl_cv_func_vsnprintf_usable=yes
+                ;;
+            esac
             ;;
         esac
         ;;
diff --git a/tests/test-snprintf.c b/tests/test-snprintf.c
index 95a352d..18efed5 100644
--- a/tests/test-snprintf.c
+++ b/tests/test-snprintf.c
@@ -60,5 +60,13 @@ main (int argc, char *argv[])
         }
     }

+  /* Test the support of the POSIX/XSI format strings with positions.  */
+  {
+    char result[100];
+    int retval = snprintf (result, sizeof (result), "%2$d %1$d", 33, 55);
+    ASSERT (strcmp (result, "55 33") == 0);
+    ASSERT (retval == strlen (result));
+  }
+
   return 0;
 }
diff --git a/tests/test-vsnprintf.c b/tests/test-vsnprintf.c
index 5060836..6711f39 100644
--- a/tests/test-vsnprintf.c
+++ b/tests/test-vsnprintf.c
@@ -73,5 +73,13 @@ main (int argc, char *argv[])
         }
     }

+  /* Test the support of the POSIX/XSI format strings with positions.  */
+  {
+    char result[100];
+    int retval = my_snprintf (result, sizeof (result), "%2$d %1$d", 33, 55);
+    ASSERT (strcmp (result, "55 33") == 0);
+    ASSERT (retval == strlen (result));
+  }
+
   return 0;
 }
-- 
1.7.4.4



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] snprintf: guarantee %1$d, for libintl
  2011-07-01 16:27         ` [PATCH] snprintf: guarantee %1$d, for libintl Eric Blake
@ 2011-07-04  0:39           ` Bruno Haible
  2011-07-05 16:17             ` Eric Blake
  0 siblings, 1 reply; 7+ messages in thread
From: Bruno Haible @ 2011-07-04  0:39 UTC (permalink / raw
  To: bug-gnulib; +Cc: Eric Blake, matthias.bolte

Hi Eric,

> diff --git a/ChangeLog b/ChangeLog
> index fcc2e6e..5f3ffb7 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,13 @@
> +2011-07-01  Eric Blake  <eblake@redhat.com>
> +
> +	snprintf: guarantee %1$d, for libintl
> +	* m4/snprintf.m4 (gl_FUNC_SNPRINTF): Require %1$d support.
> +	* m4/vsnprintf.m4 (gl_FUNC_VSNPRINTF): Likewise.
> +	* doc/posix-functions/snprintf.texi (snprintf): Update.
> +	* doc/posix-functions/vsnprintf.texi (vsnprintf): Likewise.
> +	* tests/test-snprintf.c (main): Enhance test.
> +	* tests/test-vsnprintf.c (main): Likewise.

This patch is all right.

I knew it was risky to provide an snprintf replacement in libintl that fixes
the %n$ interpretation but not the return value, and on the other hand gnulib
also may or may not replace snprintf... Thanks for all the analysis.

The changes warrant some comments, but we can add them later. I'm too tired for
today.

Bruno
-- 
In memoriam Yuri Shchekochikhin <http://en.wikipedia.org/wiki/Yuri_Shchekochikhin>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] snprintf: guarantee %1$d, for libintl
  2011-07-04  0:39           ` Bruno Haible
@ 2011-07-05 16:17             ` Eric Blake
  2011-07-07 10:51               ` Bruno Haible
  0 siblings, 1 reply; 7+ messages in thread
From: Eric Blake @ 2011-07-05 16:17 UTC (permalink / raw
  To: Bruno Haible; +Cc: bug-gnulib, matthias.bolte

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

On 07/03/2011 06:39 PM, Bruno Haible wrote:
> Hi Eric,
> 
>> diff --git a/ChangeLog b/ChangeLog
>> index fcc2e6e..5f3ffb7 100644
>> --- a/ChangeLog
>> +++ b/ChangeLog
>> @@ -1,3 +1,13 @@
>> +2011-07-01  Eric Blake  <eblake@redhat.com>
>> +
>> +	snprintf: guarantee %1$d, for libintl
>> +	* m4/snprintf.m4 (gl_FUNC_SNPRINTF): Require %1$d support.
>> +	* m4/vsnprintf.m4 (gl_FUNC_VSNPRINTF): Likewise.
>> +	* doc/posix-functions/snprintf.texi (snprintf): Update.
>> +	* doc/posix-functions/vsnprintf.texi (vsnprintf): Likewise.
>> +	* tests/test-snprintf.c (main): Enhance test.
>> +	* tests/test-vsnprintf.c (main): Likewise.
> 
> This patch is all right.
> 
> I knew it was risky to provide an snprintf replacement in libintl that fixes
> the %n$ interpretation but not the return value, and on the other hand gnulib
> also may or may not replace snprintf... Thanks for all the analysis.
> 
> The changes warrant some comments, but we can add them later. I'm too tired for
> today.

I added this comment in the .m4 files:

dnl Libintl 0.17 will replace snprintf only if it does not support %1$s,
dnl but defers to any gnulib snprintf replacements.  Therefore, gnulib
dnl must guarantee that the decision for replacing snprintf is a superset
dnl of the reasons checked by libintl.

then pushed; if you want to add further comments, go right ahead.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] snprintf: guarantee %1$d, for libintl
  2011-07-05 16:17             ` Eric Blake
@ 2011-07-07 10:51               ` Bruno Haible
  0 siblings, 0 replies; 7+ messages in thread
From: Bruno Haible @ 2011-07-07 10:51 UTC (permalink / raw
  To: Eric Blake; +Cc: bug-gnulib, matthias.bolte

Hi Eric,

Eric Blake wrote:
> I added this comment in the .m4 files:
> 
> dnl Libintl 0.17 will replace snprintf ...
> ...
> Libintl specifically favors _snprintf, with broken return value,
> even when compiled on mingw with a fixed snprintf, because the
> only behavior which it wants to fix is %1$s handling.  But this
> means that the replacement libintl_snprintf has a broken return.

While this is true for libintl 0.17, it is partially fixed in libintl 0.18.1.1
through this change:
  <http://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00202.html>

I'm applying this additional change in gettext:


2011-07-07  Bruno Haible  <bruno@clisp.org>

	Complete the change in vasnprintf.c from 2010-04-10.
	* printf.c (system_vsnprintf) [mingw]: Prefer vsnprintf over
	_vsnprintf.

--- gettext-runtime/intl/printf.c.orig	Thu Jul  7 12:46:02 2011
+++ gettext-runtime/intl/printf.c	Thu Jul  7 12:45:50 2011
@@ -1,5 +1,5 @@
 /* Formatted output to strings, using POSIX/XSI format strings with positions.
-   Copyright (C) 2003, 2006-2007, 2009-2010 Free Software Foundation, Inc.
+   Copyright (C) 2003, 2006-2007, 2009-2011 Free Software Foundation, Inc.
    Written by Bruno Haible <bruno@clisp.org>, 2003.
 
    This program is free software: you can redistribute it and/or modify
@@ -191,8 +191,13 @@
 #if HAVE_SNPRINTF
 
 # if HAVE_DECL__SNPRINTF
-   /* Windows.  */
-#  define system_vsnprintf _vsnprintf
+   /* Windows.  The mingw function vsnprintf() has fewer bugs than the MSVCRT
+      function _vsnprintf(), so prefer that.  */
+#  if defined __MINGW32__
+#   define system_vsnprintf vsnprintf
+#  else
+#   define system_vsnprintf _vsnprintf
+#  endif
 # else
    /* Unix.  */
 #  define system_vsnprintf vsnprintf
@@ -302,7 +307,8 @@
 #endif
 
 # if HAVE_DECL__SNWPRINTF
-   /* Windows.  */
+   /* Windows.  The function vswprintf() has a different signature than
+      on Unix; we use the function _vsnwprintf() instead.  */
 #  define system_vswprintf _vsnwprintf
 # else
    /* Unix.  */
-- 
In memoriam Jan Hus <http://en.wikipedia.org/wiki/Jan_Hus>


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-07-07 10:51 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1309456837-3170-1-git-send-email-eblake@redhat.com>
     [not found] ` <4E0CE519.1030508@redhat.com>
     [not found]   ` <BANLkTikdXpuNaA+Xc1GOCKOOtbegd83o0w@mail.gmail.com>
2011-07-01 13:06     ` [libvirt] [PATCH] build: fix virBufferVasprintf on mingw Eric Blake
2011-07-01 13:50       ` Eric Blake
2011-07-01 16:13         ` Eric Blake
2011-07-01 16:27         ` [PATCH] snprintf: guarantee %1$d, for libintl Eric Blake
2011-07-04  0:39           ` Bruno Haible
2011-07-05 16:17             ` Eric Blake
2011-07-07 10:51               ` Bruno Haible

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).