incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 76852] Basic : incorrect conversions Single to String and Double to String
Date Tue, 30 Oct 2012 18:59:12 GMT
https://issues.apache.org/ooo/show_bug.cgi?id=76852

damjan@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #79839|                            |review?
              Flags|                            |

--- Comment #11 from damjan@apache.org ---
Created attachment 79839
  --> https://issues.apache.org/ooo/attachment.cgi?id=79839&action=edit
Call myftoa() with nExpWidth=4 even when nNum=dMaxNumWithoutExp

Here's a possible patch.

The problem happens as follows:

print is compiled by SbiParser::Print() in main/basic/source/comp/io.cxx to
_PRINTF or such.

Somehow SbiRuntime::StepPRINTF() in main/basic/source/runtime/step0.cxx then
gets called and executes p->GetString() where p is SbxVariableRef.

SbxValue::GetString() in main/basic/source/sbx/sbxvalue.cxx is called.

SbxValue::Get() in the same file is called.

ImpGetString() in main/basic/source/sbx/sbxstr.cxx is called.

ImpPutSingle() in main/basic/source/sbx/sbxsng.cxx case SbxSTRING is then
called, and it passes a length of 6 to ImpCvtNum() as its nPrec parameter.

ImpCvtNum() in file sbxscan.cxx defines dMaxNumWithoutExp to be 1E6 if nPrec is
6, and 1E14 otherwise.

It calls myftoa(), which returns "1000000" (this is unusual - it normally
returns a decimal separator, eg. "999999.0" for 999999 and "1.000001E6" for
1000001).

Then ImpCvtNum() corrupts this string, because it expects to stop at "E" or at
the end of the string, then peel off previous trailing zeroes until it hits the
decimal separator or another digit or has peeled off nPrec (6) digits. However
"1000000" has no decimal separator and no non-zero digit, causing it to peel
off the positive powers of 10 (!!!!!!!!!!) leaving only "1".

There is 2 ways to fix the problem:
* somehow patch myftoa() to return something like "1.000000E6" instead of
"1000000"
* patch ImpCvtNum() to call myftoa() with an nExpWidth of 4 even when nNum is
equal to dMaxNumWithoutExp

My patch takes the latter approach. With it "1E6" is printed instead of "1".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Mime
View raw message