Re: [bug-gnu-libiconv] [libvirt] [PATCH] build: fix virBufferVasprintf on mingw

[Eric Blake]

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature