Mon Jun 13 09:06:00 GMT 2011
I'm having trouble verifying this patch. I think there may possibly be
another issue in newlib. When I apply the patch and build both an
x86-linux version of newlib and mn10300 version of newlib, neither pass
the test. They are both padding the result with zeroes.
Even weirder is that if I change the test to use sprintf, mn10300 gives
the expected result whereas x86-linux is not.
I need to look at this a bit more. It is currently Eclipse release
train time so I haven't had a long time to look at why my results vary.
Were you able to verify this worked and what platform did you
-- Jeff J.
On 06/09/2011 08:50 AM, Yufeng Zhang wrote:
> This patch fixes a problem in the newlib vfwprintf implementation.
> For each conversion specifier in the format string that is [feEgG], the
> current vfwprintf implementation provides only a 40-length wide-char
> buffer for conversion. This causes code like the following to misbehave.
> wchar_t largebuf;
> double val = 1.7976931348623158e+308;
> swprintf(largebuf, 512, L"%.*f", 3, val);
> Only the first 40 characters can be correctly converted due to the
> limited length of the buffer. This will cause junk in the rest of the
> converted wide-char sequence, and can potentially corrupt the memory
> immediately after 'largebuf'.
> The example code is a repro of the libstdc++-v3 test
> which currently fails when newlib is used as the C library.
> The patch was prepared with the consideration of minimum code change.
> It is probably not worth a bigger surgery in the code since the
> conversion of extremely long wide char sequence is fairly rare.
> The 2nd attached patch adds a test to the testsuite.
> 2011-06-09 Yufeng Zhang<firstname.lastname@example.org>
> * libc/stdio/vfwprintf.c (wcvt): Add new parameter 'len' of type
> int. Replace BUF with len.
> (VFWPRINTF): Add extra call to wcvt with a malloced new buffer,
> when the fixed-length buffer 'buf' is not large enough.
More information about the Newlib