Фигурные скобки вокруг expr решают, что видит компилятор байткода

Строку со скобками стоит перечитать, потому что == там тоже кое-что делает. Он сравнивает числа, когда обе стороны похожи на числа, а иначе переходит к сравнению строк, поэтому странная строка даёт просто 0, а не ошибку. Этот переход кусается и сам по себе. expr {"1.0" == "1"} даёт 1, а expr {"1.0" eq "1"} даёт 0. Если задумано сравнение текста, eq так и говорит и никогда не пробует числовое прочтение.

А с if и while происходит то же самое? Их условия ведь тоже выражения, а if $done в старых скриптах попадается чаще, чем хотелось бы.

Посчитано через tcl::unsupported::disassemble на двух однострочных процедурах. expr {$a + $b} компилируется в четыре инструкции, два loadScalar, один add и done. expr $a + $b компилируется в восемь. Загружается a, пробелы и + кладутся как литералы, загружается b, все пять кусков склеиваются через strcat, и результат уходит в exprStk, который разбирает и выполняет выражение во время выполнения при каждом вызове. Для чисел ответ тот же, а второй вариант на каждом вызове собирает строку и разбирает её.

Да, оба! if $done получает двойную подстановку, как и expr. С while хуже, потому что условие подставляется один раз, ещё до начала цикла.

set i 0
set guard 0
while "$i < 3" {
    incr i
    if {[incr guard] > 10} {
        puts "still looping, i is $i"
        break
    }
}

Из-за кавычек условие превращается в 0 < 3 раньше, чем while вообще запустится, так что while снова и снова вычисляет константу, и цикл не кончается (guard здесь только затем, чтобы демо остановилось). С {$i < 3} переменная i перечитывается на каждом проходе. То же самое с for и его условием.

Это в стороне от скобок, но в 9.1 expr {010 + 0} даёт 10, а в 8.6 ведущий ноль делал его восьмеричным, и выходило 8. В обеих версиях восемь - это 0o10, и я пошёл искать идентификаторы с ведущими нулями.

Та же двойная подстановка добирается до хостов на C, которые собирают скрипты склейкой строк. Команда, собранная через sprintf и переданная в Tcl_Eval, разбирается как текст скрипта, поэтому значение со скобками выполняется. Tcl_EvalObjv принимает команду как массив слов, которые повторно не разбираются и не подставляются, так что значение остаётся одним словом, какие бы символы в нём ни были. Это и есть аналог фигурных скобок на стороне C. Он не помогает, если одно из слов само является скриптом, например телом для eval или expr без скобок, поэтому правило всё равно должно соблюдаться в коде на Tcl, который эти слова получает.

Вот версия, которая реально могла бы со мной случиться. В маленькой форме на Tk есть поле количества, итог считается через expr $qty * $price, и кто-то вставляет в поле [clock seconds], просто посмотреть, что будет (люди правда вставляют в поля странное). Итог превращается в огромное число, и никто не понимает, откуда оно взялось. Фигурные скобки чинят подстановку. Но стоит ли полю ещё и отказывать во всём, что не число, до того как значение доберётся до expr, или скобок самих по себе хватает?

Обычно это сравнивают с параметрами привязки в SQL, и сравнение держится лучше большинства аналогий. Со скобками текст выражения фиксируется при компиляции процедуры, а $qty приходит во время выполнения как значение и никогда не читается как синтаксис выражения. Без скобок это SQL, собранный из строк и разбираемый заново при каждом вызове, что и видно по подсчёту max8.

Одна оговорка. Привязанное значение получает тип параметра. Операнд в скобках expr по-прежнему толкует по тому, как выглядит строка. Если в qty лежит 0x10, expr {$qty + 0} даёт 16, а с 1e3 получается 1000.0. Так что скобки убирают инъекцию, а для числового прочтения всё ещё нужна проверка поля, о которой спрашивал kim_dh.

Для комментария к ревью мне ближе всего «скобки передают expr выражение как написано». «Скобки ускоряют expr» - правда, но после этого их считают оптимизацией, которую можно пропустить.

В PHP это было в виде create_function, которая за кулисами прогоняла тело-строку через eval, так что всё подставленное становилось кодом. В PHP 8 её удалили, и всё, ради чего её использовали, закрывают замыкания.

После всего этого были прочёсаны мои скрипты на предмет expr без скобок, и почти везде это была просто лень. Кроме одного случая! Маленькая процедура-калькулятор делала expr $a $op $b с оператором в переменной, и скобки её ломают, потому что expr {$a $op $b} даёт синтаксическую ошибку, подстановка может дать только операнд. Понравилось решение с семейством команд tcl::mathop.

set a 3
set b 4
set op +
puts [tcl::mathop::$op $a $b]

Это обычный вызов команды, так что $a и $b передаются как слова, и ничего не разбирается дважды. Печатает 7. Построже будет switch по $op со списком разрешённых значений впереди, ведь в tcl::mathop:: есть ещё ** и <<, которые калькулятору, наверное, предлагать не стоит.

И то и другое, по порядку. Сначала проверка поля решает, готово ли значение вообще быть количеством. Берите string is double -strict $qty, потому что без -strict пустая строка проходит, и пустое поле количества дойдёт до expr и упадёт уже там, с менее дружелюбным сообщением. Когда проверка пройдена, итог считает expr в скобках. Скобки защищают вычисление от текста, а проверка говорит пользователю, что не так, ещё до начала вычисления. Пример tally6 с 0x10 тоже проходит string is double -strict, так что если шестнадцатеричное не должно считаться количеством, полю нужно ещё одно правило.

С этой оговоркой я немного поспорю. Шестнадцатеричная и экспоненциальная запись тоже дают числа, так что прочтение 0x10 как 16 и есть типизация значения, просто с более широким понятием числа, чем у пользователя. Это не та же проблема, что инъекция, и складывать их в одну кучу не хочется. Проверка поля решает, какие числа принимает форма. Скобки решают, может ли текст стать кодом. Если их смешать, легко поверить, что версию без скобок спасла числовая проверка.