Hi Eike,
Upon debugging IFS( 0, NA(), 1+0, "output" ) I came to the following preliminary conclusions:
Before ScInterpreter::ScIfs_MS() is called, ScInterpreter::Interpret is called for argument '1+0' .
That leads to a call to scInterpreter::CalculateAddSub( false ) and there the problem starts.
0 and 1 are popped and added, but after PushDouble( ::rtl::math::approxAdd( 0, 1 ) )
the raw stacktype is svError.
Unfortunately most of the time I have only a machine with 4GB available for debugging, giving 5
minutes max before freezing, so the simple question what the raw stacktype is before PushDouble
(when NA() is on top of the stack) will take me up to an hour -which I don't have right now.
Do you happen to know if in the case of a token on top of the stack of type svError (like NA()),
this stacktype is remained when pushing new values/tokens to the stack?
If that is the case, I wouldn't know a proper way to fix this, unless there are no use cases where
this behaviour is desired.
Any thoughts?
Winfried
Context
- tdf124710, unexpected result for function IFS when argument NA() is followed by an argument that needs interpreting · Winfried Donkers
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.