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

[Andreas L. <av...@lo...>]

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.