On Sun, Jan 03, 2010 at 08:15:57PM +0300, Victor Wagner wrote: > On 2010.01.03 at 14:39:22 +0300, Stanislav Maslovski wrote: > > > > > > > В ядре нужны две вещи - знание о текущей локали данного процесса и > > > таблицы перекодировки. Все остальное можно оставить в libc. > > > > Э, нет. Ты предлагал сделать setlocale() системным вызовом. Это > > потребует большего, чем имеющиеся на настоящий момент таблицы > > перекодировки. Как я уже писал выше, необходимо будет организовать > > Нет, не потребует. Потребуется только вызов > getlocale, который позволит интересующейся функции libc узнать что > думает про текущую локаль ядро.
Ты путаешь локаль и то, что зовется кодировкой локали. Просто из имени локали кодировка в общем случае не определяется, и, что еще хуже, соответствие имени локали и кодировки локали не есть нечто раз и навсегда определенное, а зависит от настроек юзерспейса и предпочтений сисадмина. Поэтому встраивать в ядро setlocale(3) смысла нет никакого. Я бы еще понял, если бы ты предложил завести отдельный вызов только под установку кодировки (условно, setioencoding(2)), который бы дергался изнутри сишной реализации setlocale(3). Но опять же, как уже обсуждалось, от перекодировки _только_ имен файлов выйдет больше вреда, чем толку. > > обратную связь с юзерспейсом, чтобы отследить, например, появление > > нового locale alias, или факт того, что отработал localedef и в > > системе появилась новая локаль, etc. > > это совершенно лишнее, Все зто прекрано обработает libc-шная обертка > вокруг соответсвующего системного вызова И у тебя получится setioencoding(). Урезанный функционал, от которого больше вреда, чем пользы. > > Все это, на мой взгляд, абсолютно лишнее, так как развитие идет в > > направлении отмирания старых восьмибитных кодировок. > > Локали - это не только восмибитные кодировки. Собственно, о чем я и толкую: локали - это в общем случае нечто гораздо большее, чем просто кодовые таблицы. Поэтому, а так же потому, что локали тесно завязаны на юзерспейс, тянуть их в ядро нет никакого смысла. > Например, из-за наличия case insensitive файловых систем в ядре не > лишними будут национальные правила upcase/locase. Имхо, лишнее, так как на таких файловых системах имена файлов подразумеваются хранящимися в одной, наперед заданной и известной на момент монтирования кодировке. Т.е., в итоге все сводится к перекодированию в юникод и обратно, а такой функционал в ядре уже есть, и неюникодные локали отмирают (дайте же им уже упокоится с миром!). -- Stanislav -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
