On windows, a query such as "cist"%d crashes cqp.exe.
"xxxxx"%c works.
=== LOGS ===
Reading a token: "cist"%d
Next token is token STRING ()
Reducing stack by rule 1 (line 360):
-> $$ = nterm $@1 ()
Stack now 0
Entering state 3
Next token is token STRING ()
Reducing stack by rule 5 (line 369):
-> $$ = nterm $@2 ()
Stack now 0 3
Entering state 9
Next token is token STRING ()
Reducing stack by rule 20 (line 407):
-> $$ = nterm $@6 ()
Stack now 0 3 9
Entering state 23
Next token is token STRING ()
Reducing stack by rule 169 (line 981):
-> $$ = nterm $@11 ()
Stack now 0 3 9 23
Entering state 92
Next token is token STRING ()
Reducing stack by rule 199 (line 1079):
-> $$ = nterm OptTargetSign ()
Stack now 0 3 9 23 92
Entering state 141
Next token is token STRING ()
Reducing stack by rule 201 (line 1083):
-> $$ = nterm OptRefId ()
Stack now 0 3 9 23 92 141
Entering state 226
Next token is token STRING ()
Shifting token STRING ()
Entering state 143
Reading a token: Next token is token FLAG ()
Shifting token FLAG ()
Entering state 229
Reducing stack by rule 210 (line 1121):
$1 = token FLAG ()
-> $$ = nterm OptionalFlag ()
Stack now 0 3 9 23 92 141 226 143
Entering state 230
Reducing stack by rule 204 (line 1090):
$1 = token STRING ()
$2 = nterm OptionalFlag ()
Bug confirmed as persisting - and seems to affect %c as well in the corpus I was testing, including the query "xxxxx"%c mentioned above as not causing the problem.
After testing cqp.exe within cmd.exe on the new Windows Terminal, I am fairly sure that this is part of a set of systematic crashes due to character encoding issues in the Windows console. When built for Windows, and used alongside Terminal, , cwb 3.4.(latest) will solve at least some of these problems - allowing us to see what persists. So I'm going to close this bug.