This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: swprintf bug?
- From: "Yufeng Zhang" <Yufeng dot Zhang at arm dot com>
- To: <jeremy dot bennett at embecosm dot com>, <newlib at sourceware dot org>
- Date: Thu, 16 Jun 2011 16:40:29 +0100
- Subject: RE: swprintf bug?
- References: <1308237220.24667.350.camel@thomas>
Hi Jeremy,
I believe this is the same issue I have been tackling. See
http://sourceware.org/ml/newlib/2011/msg00236.html
You are right about that this is generic newlib problem. The libstdc++
test you mentioned also fails on ARM due to the same problem.
The patch I sent in that email unfortunately doesn't cover all the
cases, as found out by Jeff Johnston. The patch may work for you if in
OpenRISC 1000 port that _NO_LONGDBL is defined and _MB_CAPABLE is not
defined.
I'll put on more information soon.
Cheers,
Yufeng
On 06/16/2011 04:14 PM, Jeremy Bennett wrote:
>
> I have a problem with swprintf and fixed format output. The following
> code in C++ should cause os2.str () and largebuf to end up with
> identical contents:
>
> double val2 = numeric_limits<double>::max();
> wostringstream os2;
> os2.precision(3);
> os2.setf(wios::fixed);
> os2 << val2;
>
> swprintf(largebuf, 512, L"%.*f", 3, val2);
>
> The result should be:
>
>
> 17976931348623157081452742373170435679807056752584499659891747680315726
> 07800285387605895586327668781715404589535143824642343213268894641827684
> 67546703537516986049910576551282076245490090389328944075868508455133942
> 30458323690322294816580855933212334827479782620414472316873817718091929
> 9881250404026184124858368.000
>
> However, whilst I get this result in os2.str (), in largebuf I get:
>
> 1797693134862315708145274237317043567980<junk>
>
> Has anyone seen this with other targets (it is from libstdc++-v3
> regression program
> 27_io/basic_ostream/inserters_arithmetic/wchar_t/4402.cc)?
>
> The problem occurred with the OpenRISC 1000 port of newlib (not part of
> the standard distribution), which is a minimal implementation, offering
> only standard output as a file stream. However this seems to be a
> generic newlib problem, rather than something that is target dependent.
>
> This is something I would normally report in Bugzilla, but I can't find
> the newlib Bugzilla. If anyone can point me to it, that would be
> useful.
>
> Any suggestions welcome.
>
>
> Jeremy
>
> --
> Tel: +44 (1590) 610184
> Cell: +44 (7970) 676050
> SkypeID: jeremybennett
> Email: jeremy.bennett@embecosm.com
> Web: www.embecosm.com
>