>> Это вещи одного порядка.
> Угу, угу.Угу, угу.
>> Полностью разделяю ваше восхищение (вашим умением передёргивать).
> Ну, не все умеют в телепатию.
А и не надо. Непонятно — переспросите. Только, если бы вы действительно иногда читали блог так рьяно защищаемого вами Бернштейна, вам было бы понятно.
>> . Просто те, кому
>> *действительно* нужна защита от timing attacks, находят пути её реализовать[1],
> GCC-онляи костыль, в виде повторяющегося OPTIMIZER_HIDE_VAR(neq), для – это да,
> оптимальнейшее решение!
1. http://lxr.free-electrons.com/ident?i=OPTIMIZER_HIDE_VAR
Это к вопросу у gcc-only.
2. http://lxr.free-electrons.com/source/include/linux/compiler-...
#define OPTIMIZER_HIDE_VAR(var) \
__asm__ ("" : "=r" (var) : "" (var))
В отличие от вас, я умею в телепатию. Моя телепатия говорит мне, что вы не знаете, что такое суперскалярный процессор с внеочередным исполнением. Ещё моя телепатия говорит мне, что вы гуманитарий: саркастически называя код __asm__ ("" : "=r" (var) : "" (var)) оптимальнейшим решением, вы вступаете в противоречие с самим собой, так как ранее вставали на сторону Бернштейна в его требовании обеспечить постоянное время выполнения команд сравнения (что, как раз-таки, неоптимально). В отличие от этого требования Бернштейна, конструкция __asm__ ("" : "=r" (var) : "" (var)) действительно оптимальна в том смысле, что является лишь указанием компилятору, не внося дополнительных задержек времени исполнения в сгенерированный код, и весь негативный эффект от её применения — запрет компилятору переупорядочивать в сгенерированном коде команды, зависимость по данным между которыми компилятору неочевидна. Фактически, на этапе выборки команд процессор всё равно может переупорядочить их, хотя это переупорядочивание потенциально гораздо менее опасно, чем то, что мог бы выполнить компилятор.
