Run this code Sub AcceptableSyntax Dim alpha as String alpha = "abcdefghijklmn" 'Compiles, but doesn't work Mid(alpha,3,3 = "" MsgBox alpha, 0, "Compiles, but doesn't work" 'Works Mid(alpha,3,3) = "" MsgBox alpha, 0, "Works" End Sub Line 5 should not compile and should instead throw a syntax error.
Reproducible with Version: 4.4.0.0.alpha0+ Build ID: 7d06a0601ddccc50185ea97fddcdf2ea39299096 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-07-28_06:17:50
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Reproducible with Version: 5.0.0.5 Build-ID: 00m0(Build:5)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Reproducible with version 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620
Line 7: Mid (alpha, 3.3 = "" If I write Mid(alpha,3) then it will crash "writer".
MID has two versions. One is a statement that can be written to the left of the "=". The other is a function that is always to the right of "=" sign. In the case of an instruction, Mid imperatively requires four arguments. In the case of a function, Mid imperatively requires the first two arguments, the third being optional and fourth do not exist. I take this opportunity to draw attention to the text in the online help. This text is convoluted! I think I propose a new, clearer. I confirm the issue raised in comment No. 1. Even if you add a closing parenthesis, LibreOffice crash completely and abruptly. Digging through the code, I realized Mid was entitled to special treatment by the BASIC interpreter. See it in the method "void SbiParser :: Symbol (const * KeywordSymbolInfo pKeywordSymbolInfo)", line 489 in parser.cxx. It digests bad the Mid statement and I do not know why. In the table of methods (aMethod) we have to Mid: { "Mid", SbxSTRING, 3 | LFUNCTION_, RTLNAME (Mid), 0} In the first argument, we find the reserved common name "Mid". In the second argument, the expected control result is a string. The third argument, the command is declared to have three parameters (a bug? The online help shows four parameters for instruction form (LFUNCTION_). Finally the routine running the Mid recipe is declared bear the name RTLNAME(Mid). For the last item in the table (here 0), it is the nhash variable, and I do not know yet what it is. The recipe is from Mid 1190 line methods.cxx file (RTLFUNC (Mid)).
sub Test1_Mid ' ' Instruction Mid Dim s As String s="abcdefghij" mid(s,3,3,"X") msgbox s, 0, "Résult" end sub With two brackets or no, Mid behavior (2, 3 or 4 parameters) is OK. But with: mid s,3,3,"X" = "X" Give -> ab-1fghij
The problem is not strictly the Mid statement. For example, the following code compiles and runs (result expected is "A, B, C"): Sub Main TestParenthesis("A, ", "B, ", "C" End Sub Function TestParenthesis(a, b, c) As String MsgBox a & b & c, 0, "Test parenthesis" End Function I was watching towards the translation of expressions for the treatment of parentheses in a situation of an LVALUE type of instruction. Normally, a compilation error should be raised.
Created attachment 128397 [details] Testing program for Mid function and Mid instruction This file is a Basic program to test different version of Mid as instruction, as function, with 3 or 4 arguments, with bug et sans bug.
I did a little BASIC program to test all variants of the function and the MID instruction. Try it! My search for the source of the problem leads me to the method SbiExprNode * SbiExpression :: Term (const * KeywordSymbolInfo pKeywordSymbolInfo) in exprtree.cxx, line 230 (while (etok == LPAREN)). I do not quite understand the logic here. I think the bug is here. Mid is treated as a token "SYMBOL" (line 405 parser.cxx) In fact, the method void SbiParser :: Symbol (const KeywordSymbolInfo pKeywordSymbolInfo *) is used, leading to the line 492 (parser.cxx) it bring us to the Term method previously mentioned.
A Work in progress... In exprtree.cxx, line 1057, the condition ( pExprList->bBracket && eTok == RPAREN ) || SbiTokenizer::IsEoln( eTok ) arrive when we are at the end of parameters list. Two conditions are possible. First : in an standalone expression (like Mid) opening parenthesis is present and the current token is a left parenthesis as LPAREN = '('. Second : the current token (etok) is an EOL (end of line). This was the case of Mid without parenthesis... or Mid with an opening parenthesis but without a closing one. So, I inserted code to test case where we have bBracket to True and EOL condition to True. If so, we must raise an error for a missing closing parenthesis. New code look like this: if( ( pExprList->bBracket && eTok == RPAREN ) || SbiTokenizer::IsEoln( eTok ) ) { if ( SbiTokenizer::IsEoln( eTok ) && pExprList->bBracket) { pParser->Error( pExprList->bBracket ? ERRCODE_BASIC_BAD_BRACKETS : ERRCODE_BASIC_EXPECTED, RPAREN ); } break; } I compiled and this seem to work fine. But, I must test thoroughly before submitting a patch.
Refinement: pParser->Error( ERRCODE_BASIC_EXPECTED, RPAREN );
Pierre Lepage committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=379b7ffb68bed5bc376a91032a781be147a6eff1 tdf#80731 Closing parenthesis is now detected (Mid statement and functions). It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 129841 [details] Bug Solution Report You will find here a document summarizing the search for the cause of the problem and its solution.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ecd82b5121899fe23f0ccbdd8a89c8b18436f027 Related: tdf#80731 bug in our own wizards revealed by new bracket test It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad00157b7b60fa1feb35d1e5a4f7a6d418d10f19&h=libreoffice-5-2 Related: tdf#80731 bug in our own wizards revealed by new bracket test It will be available in 5.2.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6b5a545baf516b3f835a97bb7c89aafd3f63d95&h=libreoffice-5-3 Related: tdf#80731 bug in our own wizards revealed by new bracket test It will be available in 5.3.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pierre Lepage committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=65e294e221e0ad1d37c6667eecb995817ace870d&h=libreoffice-5-3 tdf#80731 Closing parenthesis is now detected (Mid statement and functions). It will be available in 5.3.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Katarina Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6bb6ca1fb30f786385c2357e5435077066a49f82 Related: tdf#80731 missing ')' breaks Gimmicks.Autotext macro It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Katarina Behrens committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=660e394b893a045a077ccded263f94a1be03fcf9&h=libreoffice-5-3 tdf#106529: Revert "tdf#80731 Closing parenthesis is now detected" It will be available in 5.3.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Katarina Behrens committed a patch related to this issue. It has been pushed to "libreoffice-5-3-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4725c2a282f2c6468125073ba9cb5ba66f488e08&h=libreoffice-5-3-2 tdf#106529: Revert "tdf#80731 Closing parenthesis is now detected" It will be available in 5.3.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I can sympathize with people who simply want to run their old code, which they always experienced as working. On the other hand I like to have my errors escalated to me as early as possible. Also simply leaving the bug in creates a locked-in-situation, that is as long as this is not flagged as an error more syntactically incorrect but in some sense working code will likely be produced. Therefor I propose a compiler option Option Pragma Strict the default being that without this option the missing parenthesis is ignored.
(In reply to ge.huber from comment #23) Would the option be only for the problem of the missing closing parenthesis? If so, this is a lot of programming in StarBasic for an exception. Otherwise, we embark on a dangerous slope where the rigor in the respect of the grammar of StarBasic will suffer from an exception chooses unclear on what arbitrary bases. It would be better to add a comment in the list of improvements accompanying the release of the revision where the patch will appear for the first time (5.3.2, I think). Example: Correcting the missing closing parenthesis problem could have a profound impact on the functioning of existing procedures written in StarBasic. A revision of the existing codes may therefore be necessary. It will then be necessary to add the missing closing parenthesis. Regards Pierre
I'm fine with this. BTW a nice piece of detective work you've done here. Thanks for it all.
Katarina Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=351dead74b4c213b13102f81b5ae9bb47ad8ca39 tdf#106529: Revert "tdf#80731 Closing parenthesis is now detected" It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I suggest we should add an exception to macros created by extensions.
Currently I have version 5.3.2 on my workstation. The patch is implanted and therefore the missing closing parentheses are detected. I understand the issues for existing macros. Especially those where the code is in read-only mode. Myself, I had a macro that suddenly did not work any more ... because of the absence of closing parentheses;) My assessment of the situation is that the temporary withdrawal of the corrective is a wise decision. Adding a trick to bypass the BASIC code crash is not a good solution. I recall that the absence of closing parenthesis does not only concern the instruction MID. All functions of the user are also affected. It's rather embarrassing for an interpreter who also wants to be a gateway to learning programming rigorously. A possible approach would be to make available to the users an application (macro?) Which would analyze the code to detect all cases of missing closing parentheses. Here, I wonder if it is possible to take advantage of the StarBasic analyzer. But the latter is rather inconvenient with his habit of stopping at the first mistake! For a program in read-only mode, the programmer will have to get involved and update his code. If the programmer is no longer available, it will be necessary to either rewrite the code from scratch (by a good Samaritan, hum ...), or to hard code an "automatic" bypass of the detection of the closing parenthesis with the " Assumed that the read-only code was already functioning correctly. The bypass would be available for a limited time period (3 to 4 years).
So, what do we do now? Should we A) code for an exception (Volga)? B) code for an option on rigor (ge.huber)? C) tolerate the current situation and not change anything? To lose everything, I prefer b). In this case, a check box should be inserted in the IDE options dialog "Tolerate absence of closing parenthesis".
I'm opposed to c). Warn and tolerate for up to 3 or 4 years seems to be reasonable middle ground.
Here is a test dialog (see attachment 'Transitional measures.png') that introduces a new section for transitions measurements. Here we have "StarBasic Pragma Strict". I still have to make the links with the source code. Comments?
Created attachment 134331 [details] View of the proposed change.
Comment on attachment 134331 [details] View of the proposed change. I feel honoured by having the exact wording of my proposal chosen. But of course this is open to improvements, especially because it is not selfexplaining. On the other hand a Quicktip which appears on hoovering other the option might suffice.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
I am always thinking about the solution and its implementation.
Dear Pierre Lepage, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Some time has passed now, since 2014-06-30 and also since Pierre's solution on 2016-11-30. LO still does it's devil-may-care-cowboy compile and what may be worse, Pierre's crash scenario from 2016-10-04 still renders LO unresponsive. The end of the proposed "limited time period (3 to 4 years)" draws closer. The option dialog on my 6.0.7.3 doesn't even have Basic IDE Options. I'm not aware of "... an application (macro?) Which would analyze the code to detect all cases of missing closing parentheses. ". Calling this proposal D) the de facto winner n ow seems to be "C) tolerate the current situation and not change anything?" So is this ever going to change? Building on D) I want to propose E) Don't flag the error, but at least write it to some basic-compile-warning.log file, which should be mentioned in the BASIC-help system. So, what should be done now? A) code for an exception (Volga)? B) code for an option on rigor (ge.huber)? C) tolerate the current situation and not change anything? D) provide a code analyzer? E) code a warning log?
I believe that accepting code that may compile, but may not do what author intended, is bad. See https://ask.libreoffice.org/en/question/214713/vba-function-return-value-is-incorrect/. At least building in IDE should use strict rules.
My proposal would be using special versions of compile when invoked from the ide, so it would error out with explanation including "for compatibility reasons, this error is tolerated when existing legacy code is run outside of ide".
https://gerrit.libreoffice.org/81616 Please post your comments to the change. Thanks!
I agree wholeheartedly. While the revert is understandable, it is shortsighted. As your link shows people will have to dig up the error again and again. Your proposal is a great idea for a compromise.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d628258f279d003ba4e11f1f7e2e69273acd008c tdf#80731: Only check closing parenthesis when in IDE It will be available in 6.4.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.
For the record, the error is reproducible in OpenOffice.org 1.0.3.
A polite ping to Mike Kaganski: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks