Bug 145702 - Bad cint() behaviour for languages using comma as separator before the decimal point
Summary: Bad cint() behaviour for languages using comma as separator before the decima...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
7.2.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-15 15:18 UTC by Fritz R. Paul
Modified: 2023-05-29 18:01 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
The spreadsheet contains a macro function calling cint on the cell two rows left (11.36 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-11-15 15:21 UTC, Fritz R. Paul
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fritz R. Paul 2021-11-15 15:18:54 UTC
Description:
The problem occurs when the cint (string to integer) function is used in a macro on strings in which the system language (e.g. German) expects the decimal place after a comma, but in the cell we have an (English) number with a point. A system-compatible number (e.g. 530,3) is interpreted correctly (cint then returns 530), while a point (like a thousand point inserted for readability) is simply ignored. But the result for 530.3 is 5303! There can be an ambiguity in cases with three digits after the point. But in the example above, I would expect to either accept the point like a comma, or at least just ignore the point and the digit after it.

Steps to Reproduce:
1. In a system, where the comma is used in front of the decimal place, write an English number with a single decimal digit behind the point into a cell.
2. Call a macro on this cell, reading its string and calling the cint function to get the corresponding integer for this string.
3.Check the result

Actual Results:
The result using 530.3 is 5303.

Expected Results:
The expected result would be 530


Reproducible: Always


User Profile Reset: No



Additional Info:
None
Comment 1 Fritz R. Paul 2021-11-15 15:21:08 UTC
Created attachment 176274 [details]
The spreadsheet contains a macro function calling cint on the cell two rows left
Comment 2 Mike Kaganski 2021-11-15 16:11:45 UTC
I can't repro *exactly* using Russian set as program locale: both

> MsgBox CInt("123.4")

and

> MsgBox CInt("123,4")

result in "123" shown in the dialog.

However, this is still a bug.

(In reply to Fritz R. Paul from comment #0)
> But in the example above, I would expect to either accept the point like a
> comma, or at least just ignore the point and the digit after it.

The expectation in the description is wrong: what should happen is error, where the input string can't be converted to a number.

For comparison, in VBA one of the two calls above gives Run-time error "13": Type mismatch.
Comment 3 Kai Struck 2023-05-18 23:07:03 UTC
I can confirm a (mysterious) change in behaviour of the cint command in the 7er versions.
with English local language setting:
In all previous versions (and OpenOffice) something like
cint("1,a")  gave 1
cint("1,e")  gave 1
cint("1,e2")  gave 1

In LO7 all above give 0

In German local setting the "e" is suddenly treated as exponent:
In all previous versions (and OpenOffice) something like
cint("1,a")  gave 1
cint("1,e")  gave 1
cint("1,e1")  gave 1
cint("1,e2")  gave 1

In LO7:
cint("1,a")  still gives 1
cint("1,e")  gives 0
cint("1,e1")  gives 10
cint("1,e2")  gives 100

I don't know what's going on but report it here. Tested on Windows 10 and LinuxMint17 and 21.