Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL)
Description
The main concern here is that the comparison might be used in regression tests, and the wrong behavior will cause false negatives – that is, regressions might stay unnoticed.
Run the test as
CHECK_NUMBER=<number of your choosing> perl ./mtr testname
|
|
MTR test |
if ($CHECK_NUMBER < 1) |
{
|
echo # $CHECK_NUMBER is less than 1; |
}
|
if ($CHECK_NUMBER > 1) |
{
|
echo # $CHECK_NUMBER is greater than 1; |
}
|
if ($CHECK_NUMBER == 1) |
{
|
echo # $CHECK_NUMBER is equal to 1; |
}
|
Results (on 10.2, but they appear the same everywhere):
# 2147483647 is greater than 1
|
# 2147483648 is less than 1
|
# 100000000000 is greater than 1
|
# 1000000000000 is less than 1
|
Attachments
Activity
Could you clarify your question? How could one "change the MTR .test files to use a larger range data type"? What kind of "a CLI option"?
Based on my investigation, changing the ".test" file can be done with string comparison, which may not be the best option all the time. The limit on the INT datatype range in the source code can be expanded with or without via a CLI option, which resolves the above issue. The the Big-Test MTR was performed and it did not introduce any new failures.
Implementation of the overflow detection (based on the newly introduced Long Long INT data type) had caused some MTRs failing. I am actively working on the MTRs affected (around 10 out of the total number of tests in the --big-test) and will try to propose resolutions. I was just checking if causing the test to die because of overflow is acceptable by the upstream.
This is due to INT data type overflow. I am just confirming if it is expected to change the MTR .test files to use a larger range data type wherever needed, or a CLI option is required in running the tests?