>если это проблема libc, то извините - баг отпишу разработчикам libc,
>а не программу переделывать буду. Если хотите отпишу о результатах тут.
Разумно; как удобно.Только впервые слышу о проблеме с разделителями в ru_RU.* (при том, что активно применяются все три имеющие распространение вариации по кодировкам -- KOI8-R, CP1251 и UTF-8).
>> Если честно, то вместе с отношением к /tmp у меня пока пропало желание _проверять_
>>результат на пригодность
>Я ниже ответил куском кода, вам то решение не подходит?
Нет, я боюсь /tmp [*]. В данном разе не устраивает DoS, который элементарно организовывается пользователем заранее и чуточку сложнее -- в процессе функционирования (поскольку классический race condition: загружаем систему в округе возможного рестарта сервиса до повышения вероятности вклиниться между -- кстати, нерекомендуемым -- system() и mkdir(), создаём /tmp/sa и срываем работу анализатора).
* правило большого пальца -- /tmp кусается и не предназначен для постоянных или "надёжных" объектов непредсказуемого объёма. И вообще чем дальше, тем чаще наблюдается на tmpfs. А это ещё гораздо лучше, чем если угораздит остаться на корне.
По FHS подходящим местом для рабочих данных программы является подкаталог в /var/lib или /var/spool; при этом не стоит забывать, что "sa" -- очень короткий идентификатор (например, в ALT /usr/lib/sa и /var/log/sa принадлежат пакету sysstat и лично я бы слегка удивился, когда-то обнаружив /var/lib/sa из другого пакета...).
PS: я не являюсь ни разработчиком на C, ни специалистом по разработке защищённых программ, хотя принимаю некоторое участие в ALT Security Team и смежных вопросах по нашей конторе (включая поддержку нескольких серверов и выбор вариантов для того, что поставляем клиентам -- например, lightsquid, а не sarg, в качестве спутника прокси). Просьба воспринимать в таком контексте.
