Description: keying '=3333333333/100' in a cell and formatting it as a fraction with the format-string '?/???' results in '-961633963/100' see discussion in https://ask.libreoffice.org/en/question/270785/calc-funny-result-with-cell-formatted-as-fraction/?answer=270852#post-id-270852 assumed a bug resulting from integer overflow of the enumerator, as fails start at 2147483648 for it, 2<sup>31</sup> calc ver 3.5.1.2 holds til somewhat around '=1,5623*(2^38)/100' (429441754020/100) but e.g. displays 4294960000 for '=429496000000/100' despite formatted as fraction with format code '?/100', thus also 'not clean', setting ver. to oldest, setting 'regression', i've not yet checked if calculating works well for all cases, but have seen some which did, Steps to Reproduce: 1. see above description, 2. replay, 3. observe results, Actual Results: -961633963/100 Expected Results: 3333333333/100 Reproducible: Always User Profile Reset: No Additional Info: different versions, see description, as of yet tested only with win, recheck with lin appreciated,
Already in OOo, not a regression.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/18f8a7056ac7b4677f4d99aac24ed2db44010140 Resolves: tdf#137453 Implicit conversion from sal_uInt64 to sal_Int32 is bad.. It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/64d510526ec40d92efdc80438503f2e30467d2c3 tdf#137453: sc_subsequent_filters_test: Add unittest It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@erAck: looks better now, there are still limitations (now not in the value of the denominator but 'the value of the term' not exceeding 2^32-1 ?) but they are displayed properly as #FMT, thanks for fixing this bug, (i noted 'regression' as ver. 7.1 had less capa / more fail than 3.5)
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/44d17f8feca372acd41142d1b607d3360282bf30 Resolves: tdf#137453 Implicit conversion from sal_uInt64 to sal_Int32 is bad.. It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.