Bug 146590 - Basic's Str function adding unnecessary blank space before negative numbers
Summary: Basic's Str function adding unnecessary blank space before negative numbers
Status: UNCONFIRMED
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: 2022-01-05 12:33 UTC by Rafael Lima
Modified: 2022-01-05 12:58 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Lima 2022-01-05 12:33:31 UTC
Running the following code in Basic, the Str function is adding an unnecessary blank space before a negative number. The extra blank space should be added only to the positive number.

Sub TestStr
    Print "'" & Str(10) & "'"
    Print "'" & Str(-10) & "'"
End Sub

The code above returns:
' 10'
' -10'

However, running the same code above with Option VBASupport 1, I get the expected result:
' 10'
'-10'

I do not see a reason why we would need to enable VBA support to get this result.

This is being caused by the following code:
https://opengrok.libreoffice.org/xref/core/basic/source/runtime/methods.cxx?r=fffc6b40#1476

Which required bCompatibility to be enabled, or else a blank space is added to the string regardless of it being a positive/negative number.

As a side note, running the code above with Option Compatible does not fix the problem. Only adding Option VBASupport 1 fixes it. There seems to be some problem with Basic enabling Option Compatible (see also bug 145753).
Comment 1 Mike Kaganski 2022-01-05 12:58:54 UTC
(In reply to Rafael Lima from comment #0)
> However, running the same code above with Option VBASupport 1, I get the
> expected result:
> ' 10'
> '-10'

The difference is related to https://git.libreoffice.org/core/+/cb52ceae9eeeeac3b13a97b73746570315f1aa66, which implemented the different handling for VBASupport, while previously it added leading space unconditionally, in all modes. I would *guess* it was done to be backward-compatible with some code; and I'd say just keep it as is, because, while conceptually wrong, it doesn't matter much (today, even the space before positives to align with negatives is just a legacy from monospace-font terminal times), and so fixing this might create more problems in existing code expecting the spaces, than resolve.

My suggestion would be - just avoid mentioning this detail in help, if possible, and keep it as is :-)

> As a side note, running the code above with Option Compatible does not fix
> the problem. Only adding Option VBASupport 1 fixes it.

Well, this does not seem to be a problem itself. Option Compatible is compile-time option (enabling/disabling language features); runtime functions returning different results should *rightfully* depend on Option VBASupport, which is about run-time.