Overview
Artifact ID: | b4340fec32ffa83f8dfe0ed1183763a3b654bf2142135b135a8dd0e8c6b71832 |
---|---|
Ticket: | ee4d701bb3e0d0351261bfb25b87c3ac206b86cc
append.test strangely fails with -singleproc 1 (but not with 0), if it compare utf32string representations (on "constructed" smiley) |
User & Date: | sebres 2024-05-23 20:46:38 |
Changes
- assignee changed to: "nobody"
- closer changed to: "nobody"
- cmimetype changed to: "text/x-markdown"
- comment changed to:
If one would test append with -singleproc 1, test append-3.10 fails, however it shows the same internal representation. Also testing of `append-3.10` solely doesn't fail, however by match `append-3.*` it does.<br/> By an attempt to debug it, I could reduce the failing command to exactly 2 tests: ``` ./tcltest.sh -file 'append.test' -singleproc 1 -match 'append-3.6 append-3.10' -verbose tp ``` (again, without -singleproc it'd not fail at all) Strange is, if I add small output for debug to [tcltest::CompareStrings, (line 1737)](./file?ci=tip&name=library/tcltest/tcltest.tcl&ln=1737): ``` puts "***[tcl::unsupported::representation $expected]\n***[tcl::unsupported::representation $actual]\n***[expr {$expected eq $actual}]***" ``` and test it with above-mentioned command, I see: ``` ... append.test ---- append-3.6 start ***value is a pure string with a refcount of 10, object pointer at 0xd5ad60, string representation "😂" ***value is a utf32string with a refcount of 6, object pointer at 0xd62238, internal representation 0x38a2898:0x0, no string representation ***1*** ++++ append-3.6 PASSED ---- append-3.10 start ***value is a utf32string with a refcount of 8, object pointer at 0xd61db8, internal representation 0x38a0990:0x0, string representation "😂" ***value is a utf32string with a refcount of 6, object pointer at 0xd62238, internal representation 0x38a2898:0x0, no string representation ***0*** ==== append-3.10 append surrogates FAILED ==== Contents of test case: set x \uD83D string range $x 0 end append x \uDE02 ---- Result was: \U0001F602 ---- Result should have been (exact matching): \U0001F602 ==== append-3.10 FAILED ``` (so there is no string representation in the 2nd object in both cases, but one succeeds, however another doesn't) Trying to rewrite the test to a script to find the heisenbug, became confused still more - it changes the result vice versa (now in 3.6 it is not equal, but in 3.10 it is: ``` # 3.6: set x \uDE02 puts 3.6\t[expr {[set x \uD83D$x] eq "\uD83D\uDE02"}] # 3.10: set x \uD83D string range $x 0 end puts 3.10\t[expr {[append x \uDE02] eq [string range \uD83D\uDE02 0 end]}] ``` so it results to: ``` 3.6 0 3.10 1 ``` Weird. Can someone (familiar with the new unicode or utf) take a closer look here, please. My build was for windows, x86 mingw toolchain with gcc 11.2.0, configured as: ``` $ ../configure --disable-zipfs --enable-time64bit # (--disable-64bit, 'cause x86) ``` (didn't tested for other yet).
- foundin changed to: "8.7+"
- is_private changed to: "0"
- login: "sebres"
- priority changed to: "5 Medium"
- private_contact changed to: "50e9528765c18296566374b3fde2df942c394efd"
- resolution changed to: "None"
- severity changed to: "Minor"
- status changed to: "Open"
- submitter changed to: "sebres"
- subsystem changed to: "16. Commands A-H"
- title changed to:
append.test strangely fails with -singleproc 1 (but not with 0), if it compare utf32string representations (on "constructed" smiley)
- type changed to: "Bug"