Board.KolibriOS.org

А теперь финальный вопрос! Как байт кодировки там окажется?

И, кстати, этот вариант хорош ещё и тем, что значения будут совпадать с Путаницы будет меньше, потому что и там, и там будет только одна константа для каждой кодировки.

Pathoswithin wrote:Как байт кодировки там окажется?

Так а до тебя что ли не дошло ещё до сих пор? Или опять дурачка включаешь? Ладно, я пишу для всех. Может и ещё кому вдруг непонятно.

Ну, разумеется, этот байт туда положит программист. И всего-то!

Как твой вариант поможет существующим приложениям?

А ты говоришь про ввод пути при написании новых программ.

Pathoswithin wrote:А ты говоришь про ввод пути при написании новых программ.

Ну так я на твой вопрос отвечаю.

Как твой вариант поможет существующим приложениям?

Они не поломаются. Если вдруг им требуется поддержка юникода, которой в них ещё не было, то тогда в любом случае необходима правка программы с последующей перекомпиляцией.

Ты разве ещё не понял? Уже сейчас все существующие приложения получают путь запуска в UTF-8, и продолжают работать благодаря маркеру. А последнее изменение починило те, что поломались.

Да это похоже, ты ещё не понял. Мой вариант не создаёт потенциальные проблемы в будущем.
А у тебя опять всё префиксы какие-то

Просто теоретически. Программа может хотеть знать устройство, с которого запущена.
Раньше устройство было сразу после первого слэша. Теперь это не так. Потом, если будут ещё какие-то проблемы, ты, вероятно, ещё какой-нибудь костыль придумаешь с путём.

А мой вариант свободен от таких проблем.

Ну и, как я считаю, лучше всё же не UTF-8, а UTF-16. Почему я так считаю, я написал там viewtopic.php?f=2&t=3433&p=67432#p67432 но кое-что продублирую сюда, пожалуй

Ну а за UTF-16 я потому что в ней символ может состоять или из 2-ух, или из 4-ёх байтов. В то время как в UTF-8 4 варианта(1|2|3|4). Это дополнительные проверки в коде, меньше производительность. Хуже, наверное, только EBCDIC.
В плане совместимости, файловые функции уже давно поддерживают UTF-16.

И потом, если кто захочет, просто сделает UTF16ToASCII(в зависимости от локали) или UTF16ToUTF8, или ещё куда-нибудь.

*facepalm* Твой вариант не создаёт потенциальные проблемы в будущем, он сломает совместимость прямо сейчас.

Вот, придумал - пусть будут префиксы.

Но приложению передавать указатель на путь после префикса. Старые не сломаются, а новые пусть анализируют по смещению -1 или -2.

Pathoswithin wrote:*facepalm* Твой вариант не создаёт потенциальные проблемы в будущем, он сломает совместимость прямо сейчас.

Мдам... нет, ты не включил дурака, ты и есть дурак!!!

он сломает совместимость прямо сейчас

Которая уже и так была тобой сломана. А будет восстановлена.

А перекомпиляция в любом случае нужна. Так как для 1024 символов юникода 1024 байтов уже недостаточно. Поэтому, если уж делать, то по-нормальному.

Siemargl wrote:Вот, придумал - пусть будут префиксы.

Ты не придумал. Оно так и есть сейчас. Но оставлять это, плохая идея. Одна из возможных проблем там viewtopic.php?f=2&t=3429&start=75#p67405 и вон там viewtopic.php?f=2&t=3429&start=90#p67456

Можно, кстати, сделать, чтобы ядро само выделяло нужный буфер и перезаписывало указатель в заголовке. Имею в виду, если он со знаком "-" будет записан.
Заодно можно поправить ситуацию и с параметрами. То есть, сделать похожим образом. Знак "-" будет означать UTF16, а ядро само выделит буфер и перезапишет указатель. Потому что, то, как сделано там сейчас(если никто, конечно не правил больше), это странно. Должен быть указатель на буфер в bss, а там структура и необходимость её инициализации(я сам не проверял, может оно даже и не совсем так работает).

0CodErr
Давай без оскорблений.

0CodErr
Сам ты дурак, я тебе пытаюсь что-то объяснить, а ты ещё и не доволен. Зачем я вообще с тобой разговариваю? Мог бы тебя игнорировать.
Сейчас всё работает. Там, где раньше был путь в cp866, сейчас путь в utf-8. Существующие приложения редактируют конец строки и передают её в 70 функцию, которая определяет строку как utf-8 благодаря префиксу в начале. Как это будет работать без префикса?
Откуда ты взял 1024 символов? Ограничение в байтах.

Еще раз, проверюсь. Пусть #c - байт кодировки, тогда следующие примеры корректны ?

#c../aaa/file.txt - относительный
#caaa/file.txt - относительный
#c../../../aaa/file.txt - относительный, несколько многоточий

#c/pathname/file.txt - абсолютный, допустим только для SysFn70 (но clib не поймет)
/#cpathname/file.txt - абсолютный, вариант A
/#c/pathname/file.txt - абсолютный, вариант Б


Кстати, в документации по сисфункциям пример наверное некорректен
* 2,'/',0,'sys','/',0,'F',0,'I',0,'L',0,'E',0,0,0
'sys' тоже должно чередоваться с 0.

Pathoswithin wrote:Сейчас всё работает.

Иди и посмотри ещё раз на первый пост темы. Всё ли там работает?

Pathoswithin wrote:Откуда ты взял 1024 символов? Ограничение в байтах.

Ну так это и плохо.

Pathoswithin wrote:Существующие приложения редактируют конец строки и передают её в 70 функцию, которая определяет строку как utf-8 благодаря префиксу в начале. Как это будет работать без префикса?

Я тебе уже говорил как и куда можно воткнуть этот байт.

Pathoswithin, если уж так хочется засунуть байт кодировки и передавать в SysFn70, то засунь его знаешь куда? Вон туда, например
Код:

* +20 = +0x14: ?: path - zero terminated string
or
* +20 = +0x14: byte: 0 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
* +21 = +0x15: dword: pointer to string

0CodErr wrote:И, кстати, этот вариант хорош ещё и тем, что значения будут совпадать с

Code: Select all

  * +8: dword: encoding:
    * 0 = cp866 -> byte per char
    * 1 = UTF-16LE -> word per char

Путаницы будет меньше, потому что и там, и там будет только одна константа для каждой кодировки.

Leency wrote:Давай без оскорблений.

Утиная типизация же Ну а как я с ним должен ещё разговаривать? Посчитай сколько на него уже времени потрачено(и прочитать и написать) и не только про меня речь. Давно пора было ограничить ему доступ если не ко всему svn, то по крайней мере к trunk, чтобы не гадил там. А в своих бранчах хоть на голове пусть ходит. При этом, если там у него будет реально что-то полезное, то мы так же сможем это смержить с trunk-ом.
Вот такой мой пойнт. Но смотрите сами, конечно. У вас у самих же от этого проблемы возникают. Будете просто нянчиться с ним как с дитём малым. Ваше дело.