Unterminated string maybe longer than 5000 chars

[harrykien]

Hello guy, I try to compile the.exe file but I got some stuck named: Unterminated string and I tried to replace that with:

$string = "0x000....=HafloneDegree;" to $string &= "0x000....=HafloneDegree;"
and & to $string &=

Cause I read older posts that say your code to longer than 5000 chars so I replace the above when I run I got a 1 error.
Like picture 2: Func and EndFunc
I replace that with: volatile to #volatile or I put volatile with func to one line:
code: 
volatile 
Func __httprequest_statuscallback($hinternet, $icontext, $iinternetstatus, $pstatusinfo, $istatusinfolen)

to:
volatile Func __httprequest_statuscallback($hinternet, $icontext, $iinternetstatus, $pstatusinfo, $istatusinfolen)

 

Then I got a 0 error but when I run the app nothing showed or not working, or get stuck.
IDK what I was wrong from where also the compiled got 0 error.
Thank for your help.

Spoiler

 

 

Edited March 5, 2023 by harrykien

[mistersquirrle]

Are you sure that Volatile is what you want? https://www.autoitscript.com/autoit3/docs/keywords/Volatile.htm It might be causing some problems itself.

As for your string, the variable can hold more than that: https://www.autoitscript.com/autoit3/docs/appendix/LimitsDefaults.htm, up to 2,147,483,647 for max string length, however for a single line in the script, only 4095. Just using an ampersand (&) will not solve the issue, as it's still a single line. You'll need to create a new line with $sVar &= 'More text'. If this is an issue of too long of a string in your script itself, just take some more time to do something like:

Local $sLongString
$sLongString = 'blah 1'
$sLongString &= 'blah 2'
$sLongString = $sLongString & 'blah 3'

And just make sure that no single line is more than 4095 characters. You also do not have to break the lines cleanly, you can break them where ever, so I'd stay away from trying to get 4095 exactly.

Another option is to save/write that long string to a file, and read it from the script:

Local $hFile = FileOpen('LongString.txt')
Local $sLongString = FileRead($hFile)
FileClose($hFile)

 

If you're still having issues then please post a section of the code that you're having an issue with if you can, so we can better understand the issue.

Edited March 5, 2023 by mistersquirrle

[Nine]

Easiest way for you would be :

Local $sVeryLong = "blah blah1" & _
"blah blah2" & _
"blah blah3"

Remember line length in AutoIt is limited to 4095 characters. (see limits here)

[pixelsearch]

ampersand & is not enough (as shown in your pic) but "ampersand space underscore" should do it in any case, using a single variable :

Local $sString = _
    "aaa...." & _ ; 4000 "a" characters in this line
    "bbb...." & _ ; 4000 "b" characters in this line
    "ccc...." & _ ; 4000 "c" characters in this line
    ...       & _
    "zzz...."     ; last line

You can go on and on like this (I just tried it with a string variable having 100.000 characters length) and there were no error in Scite or in a compiled script because :
* Each line doesn't reach the 4095 limit in Scite
* The variable string lenghth is < 2,147,483,647

Of course, having a 100.000 length string directly in your script isn't really user friendly (it would be better to place it in a separate file as mistersquirrle indicated) but still, it's doable, without error, to place it directly in your script.

If I wrote something incorrect, please be kind to comment because I'm actually working on this in another script.

Edit: Nine typed it 3 seconds b4 me 

Edited March 5, 2023 by pixelsearch

[pixelsearch]

@Nine while doing some tests (which should be important in my future update of RegExpQuickTester 2.5) , I'm now a bit perplex concerning the way we both answered OP's issue. Why is that ?

Let's say each line below is about 2.000 characters length (shortened in this output of course), the string containing internally @lf's (no big deal, it could have been @cr or @crlf or any mix of the 3) and the string length being more than 300.000 chars.

1) If we do it by adding the trio "& _ " at each line end, as we both did above, then the output is basically this one :

Local $sSubject = '</pre>' & @lf & '<p class="level1">' & @lf & _
    '&nbsp;machine host.domain.com' & @lf & '&nbsp;login myself' & _
    '........' & _
    '<p class="level1">For example, you can do both a GET and a POST in a single command line:'

I did that on a 355Kb html source file (curl - How To Use.htm) and got, randomly, this Au3check error :

error: yacc stack overflow 

This error appeared too, randomly, when using other source files, which were also big, but shorter. I also got the same error a few days ago, randomly, when using this syntax.

2) Now If we do it the way @mistersquirrle indicates it above (also @BrewManNH in this post, who answered @legend getting also the "yacc stack overflow" 2 posts above), then it doesn't generate an error, when using the same sources :

Local $sSubject = '</pre>' & @lf & '<p class="level1">' & @lf    
      $sSubject &= '&nbsp;machine host.domain.com' & @lf & '&nbsp;login myself'
      $sSubject &= '........'
      $sSubject &= '<p class="level1">For example, you can do both a GET and a POST in a single command line:'

For now I can't be 100% sure the 2nd way won't ever throw an error, but after I'll update RegExpQuickTester, it will be easy to copy a generated code totally functional, paste it in a new script, then run directly the script. We'll be able to test it on several big subject files, in a snap (I'm testing it a lot these days, when I got time, thanks to @ioa747 who gave me this idea a few weeks ago)

Of course, one should not insert such huge strings in a script (a text file should be preferred) but the question still remains : if the way 1) generates from time to time a "yacc stack overflow" when the way 2) never generates it, then the choice should be to always use the way 2) as soon as the string is a very big one.

For the record, I always used syntax 1) until now. Only today I started with syntax 2) . That's why I can't be sure syntax 2) is 100% "errorproof" as it's new for me. We'll see where it goes... in a few days/weeks 

[mistersquirrle]

@pixelsearch I did some testing and the actual length of the string didn't matter, but I got the yacc stack overflow error after 250 lines, both when the lines were 4000 chars each, and when they were just 3 chars each, when it was like "1" & @LF & @LF & _. I then tested it as "1" & @LF & @LF  & @LF  & _, and it failed at 187 lines, with 4x @LF it failed at 150 lines, line 107 with 6x @LF. It also didn't matter if it was LF or CRLF.

When I put the @LF or @CRLF into a separate variable, I had no issues until I added more lines, then with 6x line breaks in a variable it failed at 374 lines. Same when I made the variable 12x and 24x line breaks, so that overflow was unrelated to the amount of linebreaks.

So now I figure it's just the amount of &'s used per line. So with just '' & _, it fails at line 748. With just a bunch of '' & '' & '' & '', it failed at column 3756 on the first line (still yacc overflow). So that was right before the 748th &, and before any underscore to go onto a new line, even without any extra lines with _.

So there's some more information on it, whatever yacc is fails after 747 &'s for a single "line". Doing 747 &'s then a new line with $sString &= '' & '' & '' & '' works fine, even after 1000 lines of 747 &'s onto the same string.

Edited March 5, 2023 by mistersquirrle

[pixelsearch]

@mistersquirrle that's interesting !
If I understood your conclusion, &= will nearly never throw a "yacc stack overflow error" (with usual big strings) when & _ will throw the error much often.

Gladly I already got functional code to generate automatically these long strings to be pasted in Scite. It's useful, for example to test your comments, without creating manually the strings. Let's say first we generate this test string :

1) Script "420x - copy a string to Clipboard.au3"

#include <String.au3>

Local $s = _StringRepeat("1" & @lf, 1000)
ClipPut($s)

2) Script "RegExpQuickTester 2.5m.au3"

Paste the string in the Subject field
Generate AutoIt code (which includes a generated Subject String for Scite)
The generated Subject string can actually be created in 2 different ways as discussed in my precedent post.
But it won't stay like that forever : one of these 2 ways has to be deleted !

3) Script "420y - paste RegExp code here & _.au3"

If RegExpQuickTester did generate the Subject string like this...

...then what you experimented happens to me too, at the very same line :

4 hours ago, mistersquirrle said:

it failed at 374 lines.

My Scite Console :

"420y - paste RegExp code here & _.au3" (374,15) : error: yacc stack overflow

@Jos comment was interesting in this post, related to "unterminate string", when he wrote :

"Anyway, you can also opt for not running au3check, but you will still have to fix your code to ensure it runs with autoit3."

He's right, if we don't run Au3check in this special case, then we won't be warned about this "error: yacc stack overflow" and the script will still run without error. But who likes to run a script without running Au3check before ?

4) Script "420z - paste RegExp code there &=.au3"

If RegExpQuickTester did generate the Subject string like that...

...then 3 lines only are enough and pasted in Scite, each one being approx. 4000 characters
Which means about 333 & and 333 @lf per line
Au3check won't signal any error, great !

Concerning this last test, let's push the limit and multiply by 100, which means repeating the string 100.000 times :

Local $s = _StringRepeat("1" & @lf, 100000)

300 lines in Scite, each one being approx. 4000 characters
Which means about 333 & and 333 @lf per line
Au3check doesn't signal any error, great !

My conclusion (same as yours) is that it seems better to use &= rather than & _ when it comes to big strings splitted over several lines. It will avoid the "error: yacc stack overflow" with nearly all usual big files contents, when transformed to a single string pasted in Scite.

We just need to remember the 4095 characters size limit for a single line pasted in Scite.

Edited March 6, 2023 by pixelsearch
typo

[Jos]

3 hours ago, pixelsearch said:

@Jos comment was interesting in this post, related to "unterminate string", when he wrote :

"Anyway, you can also opt for not running au3check, but you will still have to fix your code to ensure it runs with autoit3."

He's right, if we don't run Au3check in this special case, then we won't be warned about this "error: yacc stack overflow" and the script will still run without error. But who likes to run a script without running Au3check before ?

The stack size has been increased a few times since then so now the question is whether this is a real-life example that makes it fail and should be supported?
The thing to remember is that there will always be a limit which you can cross whatever I make it.

[pixelsearch]

6 hours ago, Jos said:

The thing to remember is that there will always be a limit which you can cross whatever I make it.

Thanks for your input 
imho, the stack size you increased several times shouldn't be changed anymore, because there IS already a solution to solve this kind of situation, I'll indicate it again at the end of this post.

First, let's have a look at another Forum thread, dated from 2016, title "error: yacc stack overflow". In this thread, OP showed a string having 261 lines and his comment was :

"This code causes an error: yacc stack overflow on line 249"

Global $g_R2 = '1|0.1382|0.0031' & @CRLF & _
    '2|0.1696|0.003' & @CRLF & _
    '3|0.1994|0.003' & @CRLF & _
    ....
    '258|26.3468|0.0062' & @CRLF & _
    '259|26.4083|0.0062' & @CRLF & _
    '260|26.47|0.0059' & @CRLF & _
    '261|26.5295|0.0056'

Jos answered in the same thread :

"I can fix the stack overflow with au3check in case is required by increasing it."

Jos certainly increased it, as OP's string will actually (in 2023) generate the error when it reaches this limit :

"(374,38) : error: yacc stack overflow"

Now if we remove a single line from the string, the error disappears :

No yacc error in the pic above
Then I was intrigued when OP wrote :

"Replaced @CRLF on a colon delimiter (:)  and all was good. Thank you."

Why intrigued ? Because the following code still generates the error, which shows that @CRLF has nothing to do with the "yacc stack overflow" error (thanks to @mistersquirrle who indicated it in his post above)

(374,36) : error: yacc stack overflow

Now If we divide the number of ampersands (&) by 2, after integrating the colon that solved OP's issue, the limit is reached below, when the number of lines is doubled :

(748,31) : error: yacc stack overflow

Removing 1 line makes the error disappear :

No yacc error in the pic above

So this yacc error is really related to the number of ampersands (&) found in code while a string is being parsed. It has nothing to do with the line breaks or any other character (if I'm not mistaken)

@Melba23 answered this to OP :

"At a guess you are running into some form of line limit within Au3Check - hence the "yacc" error. Have you thought of changing the manner in which you store the data? Perhaps an array might be more suitable than a @CRLF delimited string."

imho the answer we all should give to users facing this situation is :

"If you really want to integrate this kind of string directly in your script, then don't use the & _ syntax, but use the &= syntax to get rid of this yacc error"

This last picture will show you why :

10.000 lines, no yacc error and all is good.

6 hours ago, Jos said:

Now the question is whether this is a real-life example that makes it fail and should be supported?

The example indicated by mistersquirrle  ('' & '' & '' & '' failed at column 3756 on the first line) isn't a real-life example and will still generate a yacc error. He indicated it just for tests.

Real-life examples (as discussed above) shouldn't face the yacc issue anymore... if the syntax &= is used.

Edited March 6, 2023 by pixelsearch
typo