Apache OpenOffice (AOO) Bugzilla – Issue 37661
Basic: Odd return from Mod operator
Last modified: 2017-05-20 11:31:16 UTC
According to Help page "Mod-Operator [Runtime]" "print 10 mod 2.5 REM returns 0" but '10 mod 2.5' actually retunrs 1. It should return 0, as described in Help.
Hi Andreas, can you take a look
OOo Basic converts the numbers to integer/long before performing the operation. This differs from VB behaviour, but is an unusual scenario -> Started, OOo later P2 -> P3 (please read the priority rules before setting a task to P2)
What's wrong with this one being P2? One of the P2 criteria says "Basic functionality is not working correctly." Mod (equivelant to the % operator in C and Java) is a very principle arithmetic concept, and it is not working as implied in Help. It is also said "Issues with this priority(P2) must be fixed before release." It can be achived by tweaking the Help (such as correcting the REM statement and adding a known limitation.)
The main statement in the P2 description is: This priority describes major bugs. And of course the word "basic" often used in the following lines isn't used in the sense of "OOo Basic" here but in the sense of "fundamental, elementary". This really is not very carefully worded. So "Basic functionality is not working correctly." means something like "Writer cannot handle tables any more" or "A wizard does not start any more, e.g. be- cause of a OOo Basic problem". Mod may be a very principle arithmetic concept but mainly in the context of inte- ger arithmetics. C++ does not even accept the % operator for double arguments. So for me, this issue perfectly meets the P3 criteria "single function doesn't work the way it is supposed to be". I also checked previous versions. It does not occur in StarOffice 5.2 but in StarOffice 7 / OOo 1.1. A problem that has been undetec- ted for years in general doesn't look like a major bug to me. And there's always the danger of breaking Basic programs (unintentionally) based on the StarOffice 7 behavior, even if it's wrong. And yes, "Issues with this priority(P2) must be fixed before release." but this does only mean that they have to be fixed IF they meet the P2 criteria. The other way "I want to have this task fixed before release, so I choose P2" does not work. -> Stays P3 / Office later for now
A problem that has been undetected for years is more like a proof that the product is not adequately tested. Besides, if it was OK in StarOffice 5.2, isn't it something we call a "regression" ? Seems like we have just found a perfect reason for the earlier target.
Yes, it's regression, but somewhere between StarOffice 5.2 and 7 and not between 7 and 8. So this is a perfect reason to be careful, because the wrong behaviour was active for a long time. But to come back to the start of the discussion: Under no circumstances this is a P2 and there are a lot of bugs also targeted to OOo Later that worry me far more than this one. So I can have a look if there's some time left and compare win against risk again if the fix is easy, but for now I still don't consider it to be of superior importance.
Sorry, but I don't set priorities based on your workloads and other far more important issues that I know nothing about. If I set P2 and you don't like my point of view or think under no circumstances it is acceptable, please make the priority field hidden so I should not even bother to think about it in the first place.
Reset assigne to the default "issues@openoffice.apache.org".