Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw
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/pr...
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)