Summary: | BASIC: Data Type Characters with literals don't affect resulting value type | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Mike Kaganski <mikekaganski> |
Component: | BASIC | Assignee: | Andreas Heinisch <andreas.heinisch> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andreas.heinisch, himajin100000, jag |
Priority: | medium | ||
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=129596 https://bugs.documentfoundation.org/show_bug.cgi?id=130677 https://bugs.documentfoundation.org/show_bug.cgi?id=143707 https://bugs.documentfoundation.org/show_bug.cgi?id=151171 |
||
Whiteboard: | target:7.0.0 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 127592 |
Description
Mike Kaganski
2020-02-06 06:50:50 UTC
(In reply to Mike Kaganski from comment #0) > The trailing data type characters # and & at the literals Please ignore the "#", which is a leftover from experiments, and is not expected to work (at least, it doesn't in Excel). Confirmed with Version: 6.3.3.2 (x64) Build-ID: a64200df03143b798afd1ec74a12ab50359878ed CPU-Threads: 6; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL See SbiScanner::NextSym for hex/octal numbers (and no GetSuffixType call there). I already implemented the change on my local machine, but I'll wait until https://gerrit.libreoffice.org/c/core/+/90858 has been sumbmitted in order to rebase the change on it to avoid some side effects I encountered with SbiOpcode::CONST_. (In reply to Andreas Heinisch from comment #4) > I already implemented the change on my local machine Great! Sorry if that disturbed you: I just came across this code and decided to post it as a code pointer in case it would be useful. Thank you! Do we consider the String type as well in basic/source/comp/symtbl.cxx? (In reply to Andreas Heinisch from comment #6) > Do we consider the String type as well in basic/source/comp/symtbl.cxx? I didn't check that - but likely yes, since we can declare string variables using something like > Dim s$ No idea what should it do for things like > Dim s : s = 123$ Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/384afeaa3df919585d9df1df5b4cf6c93536e319 tdf#130476 - take into account trailing data type characters It will be available in 7.0.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. Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ffbcbbc8dcc946d4d91cc08a937c2067be5a18b7 Cleanup for tdf#130476, tdf#62323 and tdf#62326 It will be available in 7.0.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. (In reply to Mike Kaganski from comment #0) > Consider this code: > > > > sub typesnames > > ' Integer % - doesn't work, Long & > > ' This should print Integer Long, but prints Integer Integer > > MsgBox TypeName(&hff) & " " & TypeName(&hff&) > > end sub > > As mentioned in comment, is should output "Integer Long", but gives "Integer > Integer" instead. ... My attention only was drawn to this bug by announcing it fixed in 7.0. Why did you expect as you did? I dont't know anything about the usage of type-declaration characters with constants. Is there something like a specification? q& = &hff works as expected. From my point of view the bug is that a trailing type-declaration character appended to a constant is accepted at all. It should throw an error. You may expect to get a Long value by &h00000FF . Hmmm? Shall the implicit type be determined by the value or by the syntax? Specify it! Currently you get a Double value for &h100FF. That's a bug? You cannot tell a bug from a feature if there is no specification. (The idea of implicit type declarations was a misconception from its beginning with FORTRAN. In the 1950ies there was an excuse, however. Now is none.) What actually is missing is a conversion function like CLong(). Pascal has a well proven concept insofar: The name of any simple type can be used as the name of the respective conversion function (where applicable). Double(1) |