Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[EricT <tw...@gm...>]

Hi, Andreas

Jan has already implemented the changes for subst, they're in the tip-672
branch. I don't use the command much so I can't say for certain that it
solves the problem.

That was a nice summary of the current choices. You left out the one that I
actually like the best, the $=(...) option. It only breaks very rare cases
where someone wants a literal $= and can easily modify it to \$=
anyway, and likely already has by not realizing it wasn't needed.

But there's one little twist I've been playing with, that can drop the
outer ()'s as long as you don't need any whitespace outside ()'s, and you
can always add them if you do:

% set X 2; set Y 625 ; lrange [lseq 0 to 50]    $=$X*2-1    end-$=int(
sqrt( $Y ) )
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Sorta like index expressions with regards to whitespace. Not too much of a
change.

On Wed, Oct 29, 2025 at 6:38 PM Andreas Leitgeb <av...@lo...> wrote:

> Jan Nijtmans <jan...@gm...> wrote:
> > 3) The "subst" command (and the Tcl_SubstObj() function) need
> >     new options/flags to handle the new "expression" substitution,
> >     separate to "variable" substitution and "command" substitution.
> >     That solves the discussion, whether this substitution belongs
> >     to "variable" or "command" substitution. I think it is neither ;-)
>
> This is very dangerous, imho:
>
> If some code contains:    ... [subst -nocommands $userString]
> then the subst shall never ever cause any command to be called,
> no matter how it appears in the $userString.
>
> E.g. if $userString is {foo bar [exec snafu] } then the command "snafu"
> just should not be executed...  ("snafu" might just as well be "rm -rf /")
>
> Now, if expr-subst gets considered a "different" thing, then code like
> the one above might end up executing snafu, if $userString is just slightly
> modified to {foo bar $(([exec snafu]))}, which definitely is a severe
> breach of "subst"'s promises. Existing code shouldn't be forced to add a
> new option to all "subst -nocommands" invocations to not become vulnerable.
>
> PS: some more opinions on this topic:
>
>   - I like empty-named arrays and use them quite often, so I'd
>     consider $(...) redefinition for expr out of way until maybe Tcl 10.
>
>   - $((...)) is fine by me, and I'm proud of having (a while back) started
>     a discussion that led to disallowing certain characters in literal
> array
>     indices.  My motivation back then was paving the way for assignment
> (even
>     to array elements) within expr - without ambiguity with
> builtin-functions.
>
>   - [(...)] looks good to me, too - I think the compatibility issues are
>     rather theoretic. If brackets are necessary, to allow subst -nocommands
>     to do its job correctly, then this would be my preference.
>
>   - [= ...] with a modified expr-language using barewords as variable
>     names would probably solve many (if not most) of the cases, where
>     [expr {...}] really "hurts" for its verbosity.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>