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/print... 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