[Issue 112383] CLng(HFFFFFFFF) fails on 64-bits rather than returning -1
https://bz.apache.org/ooo/show_bug.cgi?id=112383 dam...@apache.org changed: What|Removed |Added Target Milestone|--- |4.1.2 --- Comment #10 from dam...@apache.org --- (In reply to Kay from comment #9) (In reply to damjan from comment #8) Hi Kay, I don't understand. Help - The Target Milestone field is used to define when the engineer the issue is assigned to expects to fix it. (1) It's already fixed in SVN HEAD, and (2) it was never assigned to me. What else does Target Milestone mean? I had never looked at the Help for Target Milestone before, so this is interesting information, and thank you for brining this to my attention. As many of the original engineers assigned to OpenOffice issues are no longer with the project, we have been relying on actual committers/fixers to set the Target Milestone. In this sense, we use Target Milestone to mean the version of Apache OpenOffice in which we expect the fix will be delivered. Ok thank you, I've set it. I am confused about how Target Milestone, Release blocker, and copying the patch to a release branch are interrelated though? -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 112383] CLng(HFFFFFFFF) fails on 64-bits rather than returning -1
https://bz.apache.org/ooo/show_bug.cgi?id=112383 --- Comment #9 from Kay ksch...@apache.org --- (In reply to damjan from comment #8) Hi Kay, I don't understand. Help - The Target Milestone field is used to define when the engineer the issue is assigned to expects to fix it. (1) It's already fixed in SVN HEAD, and (2) it was never assigned to me. What else does Target Milestone mean? I had never looked at the Help for Target Milestone before, so this is interesting information, and thank you for brining this to my attention. As many of the original engineers assigned to OpenOffice issues are no longer with the project, we have been relying on actual committers/fixers to set the Target Milestone. In this sense, we use Target Milestone to mean the version of Apache OpenOffice in which we expect the fix will be delivered. -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 112383] CLng(HFFFFFFFF) fails on 64-bits rather than returning -1
https://bz.apache.org/ooo/show_bug.cgi?id=112383 Kay ksch...@apache.org changed: What|Removed |Added CC||ksch...@apache.org --- Comment #7 from Kay ksch...@apache.org --- Please assign Target Milestone. Thanks. -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 112383] CLng(HFFFFFFFF) fails on 64-bits rather than returning -1
https://bz.apache.org/ooo/show_bug.cgi?id=112383 --- Comment #8 from dam...@apache.org --- Hi Kay, I don't understand. Help - The Target Milestone field is used to define when the engineer the issue is assigned to expects to fix it. (1) It's already fixed in SVN HEAD, and (2) it was never assigned to me. What else does Target Milestone mean? -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 112383] CLng(HFFFFFFFF) fails on 64-bits rather than returning -1
https://bz.apache.org/ooo/show_bug.cgi?id=112383 dam...@apache.org changed: What|Removed |Added Resolution|--- |FIXED Status|ACCEPTED|RESOLVED --- Comment #6 from dam...@apache.org --- Patch committed, resolving fixed. Thank you for your bug report! -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 112383] CLng(HFFFFFFFF) fails on 64-bits rather than returning -1
https://bz.apache.org/ooo/show_bug.cgi?id=112383 --- Comment #5 from SVN Robot svn...@dev.null.org --- damjan committed SVN revision 1697984 into trunk: #i112383# CLng(H) fails on 64-bits rather than returning -1 -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 112383] CLng(HFFFFFFFF) fails on 64-bits rather than returning -1
https://bz.apache.org/ooo/show_bug.cgi?id=112383 dam...@apache.org changed: What|Removed |Added CC||dam...@apache.org OS|All |Unix, all Latest|--- |4.1.1 Confirmation on|| --- Comment #4 from dam...@apache.org --- Bug happens only on LP64 systems (all *nix and MacOS X, but not Windows which is LLP64) due to the fact the long l in function ImpScan() in main/basic/source/sbx/sbxscan.cxx is 64 bits as opposed to 32 bits on the IL32 systems the code was written for. As a result, the long l doesn't overflow, which is why it gets to 4,294,967,295, exceeding the maximum value of a 32 bit variable which is 2,147,483,647, at which point it should have wrapped and become negative, eventually reaching -1. The fix is easy, either it needs to be converted to another type (eg. int or sal_Int32) to stay 32 bit on LP64 systems, or the long l can stay but needs = 0x and then sign extension back to 64 bits before reading it to assign to nVal and comparing it against SbxMININT and SbxMAXINT. But I am concerned that on LP64 systems there might be many other places with bugs such as this... -- You are receiving this mail because: You are on the CC list for the issue.
