> а если проблему с гонами какой-то из пользователей пытается вызвать сознательно -- точно ли не удасться это ему?Прежде чем обсуждать угрозы, надо представить себе модель атаки. Вот допустим, я в своей домашней генте поставил этот самый zapcc в качестве CXX. И как должна быть организована атака? Кто-то должен выполнить произвольный код на моём компе, чтобы отправить в zapcc запущенном из под рута что-то там на компиляцию? Если на моём компе выполняется чей-то произвольный код, то ему проще не дожидаться, когда я поправлю CXX, а сделать что-нибудь интереснее, например, прописать в ~/.bashrc какой-нибудь интересный alias на su/sudo, чтобы когда мне захочется получить права рута, эти права достались бы и вредоносному коду тоже. Или если хочется извращений, то можно подменить весь сервер zapcc, а не обращаться к существующему -- всего-то надо прибить старый и запустить новый.
Или может у меня фантазии недостаточно, и есть какой-нибудь способ использовать этот zapcc без выполнения произвольного кода? А! Точно! Я придумал. Если сервер запустить на хорошем и мощном компьютере, а emerge на слабом и тупом, то zapcc позволяет избавиться от distcc. Но тут встанет вопрос как их безопасно связать, чтобы никто не вмешался... Но, всё же, я бы не стал на месте разрабов компилятора заморачиваться этой хнёй, достаточно дать возможность пользователю соорудить ssh-тоннель между сервером и клиентским компом, и пускай пользователь сам следит за правами доступа так, как он считает нужным.
> и точно ли компилятор вообще проверяет привелегии различных пользователей компьютера?
Если интересно, загляни, посмотри. Зачем гадать? Как по мне, тут не проверки нужны, а что-нибудь типа передачи сборочных команд серверу через unix-сокет с правами по умолчанию 0600: я вообще не вижу никаких юзкейсов для сборки, которая идёт из под нескольких пользователей одновременно.
> а точно ли там в конце-концов -- нет утечек памяти?
Утечки памяти -- это плохо, но если за счёт утечек памяти достигается ускорение сборки в несколько раз, то я за утечки памяти. В конце-концов, не сложно и перезапустить раз в сутки.
> а зачем вообще думать про безопасность компьютера разработчика?
Если разработчик со скуки клонирует рандомные репы и делает в них make, то ему никакой компилятор не поможет против rm -rf ~/*, затесавшимся промежь прочих команд в одном Makefile'ов.
> точно ли получаемый на выходе результат -- является ровно одинаковым по сравнению с тем как если бы компилятор был был запущен в первый раз без кэша?
Вот это интересный вопрос. В C/C++ есть куча способов получать разные результаты компиляции, выполняя include из разных контекстов, и действительно интересно, как этот компиль справляется с отслеживанием контекста.
Ещё интересно, как он будет справляться с перекомпиляцией сорцов после внесённых изменений. Насколько успешно он отслеживает зависимости или изменение одной строки в одном файле приводит к сбросу кеша в ноль и пересборке с нуля? С одной стороны -- это не его забота, этим должна заниматься система сборки, а с другой стороны не совсем не его, он мог бы делать это эффективнее, чем система сборки.
