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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list