Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

[Andreas K. <and...@gm...>]

> One of mine is such an extension (*, **), which is why I ran into the
> issue when I executed the test suite against a near-current Tcl 9
> commit (3 days old) and got a load of test failures I knew had worked
> before with a commit from near the beginning of the year.
 
> I am willing to a accept the change, given the reasoning from the
> ticket, and given that I can change my code to detect the
> single-element list int.rep and then undo the wrapping to get at the
> actual and desired value.

[please read to the end before responding to parts]

Actually the change fully breaks my current code, and thus all other
extensions using values which have no string rep (*) doing the same
kind of pass-through through `expr`. Passing such a value through
`expr` now fully strips their precious int.rep, with no recovery.

Because the conversion of the value with the unknown type to List
first generates a string rep, then converts that to List int.rep, and
this second step is where we lose the original int.rep and thus the
actual value.

I was still able to fix the issue for me, by avoiding `expr`
completely.  I.e. instead of a trinary operator `?:` I now use an
`if`-command. Luckily it seems that it was only that one place where I
did such a pass-through.

I will also have to note this in big bold red text in AKTIVE's
documentation for its users, as passing of image values through `expr`
is now forbidden.

(*) These are hopefully not that many.

Note: In AKTIVE the code returns a pseudo-string rep of "<aktive::image>".
Not sure if I can leave the Tcl_UpdateStringProc as NULL. I suspect
that would trigger an error in many a place.

> Given how I stumbled into this I would recommend and ask to place a
> note about this into the compatibility notes as something extension
> writers may have to be aware of.

I would like to strengthen my recommendation for a compatibility note.

> (*) https://core.tcl-lang.org/akupries/aktive/doc/trunk/README.md
>     uses Tcl_Obj values to carry images. Which may be large. So I
>     decided against dealing with a string rep which will not only
>     materialize the entire block of pixels into memory, but worse, as
>     some form of text.

To elaborate a bit more, as inspired by VIPS, AKTIVE is about
performing image ops on (very) large images __without__ having to
materialize the entire image in memory, just the pieces currently
processed, i.e. a few rows, columns, or other small tiles.

Having such then materialized because `expr` wanted/needed a string
rep to decide quicker that it cannot work with the value ...

... that now looks to me to be pretty much the original ticket, for
any extension providing Tcl_ObjTypes with possibly large string
reps. I.e. the slow detection is only fixed for builtin types, not
extension types.

Note, I am __not__ arguing for undoing the change.
It is arguably better than before.
Only that we should be aware of its limitations too, wrt extensions.

More stuff for the compatibility notes.

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------