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 n
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 sp
[adding bug-gnulib, bug-gnu-libiconv]
On 07/01/2011 04:50 AM, Matthias Bolte wrote:
> 2011/6/30 Eric Blake :
>> 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
>>> print
2011/6/30 Eric Blake :
> 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 vsnprin
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.
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 Matt
