Как в ядро Linux передаются строки?

Ну да, тогда они ничего ещё не решали. Но они и потом не заменили слеш на нормальный, когда, например, переходили с DOS на Windows, или ещё при каком-нибудь случае. Да и слеш не самый показательный случай.

До сих пор вот расхлёбываем.

Чё уж тут говорить, я в своём интерпретаторе браифака (уж где где не ожидал) вчера весь день провёл рвя волосы на жопе. Проверял на разном коде, некторый код не работал, но должен, стучался головой об клавиатуру пока не понял что программа ожидает ввода заканчивающегоня на \n а в тестах которые видимо были написаны на винде всё на \r\n заканчивается, а я то блин всё переколупал. Ладно понял принял добавил ключи приведения ввода к разным EOL, затем другой код опять блин не работает, а он явно ожидает \r вместо \n и его выводит потом переврдя каретку и переиспользует для вычисления следующей ячейки блин, ну здрасти пришлось ещё делать ключи для принудительного преобразования конца строки так как это поведение вшито в brainfuck программу. И уже вот такая говня в ключах интерпретатора

 Some brainfuck programs expect different behavior for
   end of line. Setting bottom transparent fix input for
   different behavior end of line. LF , CR, CRLF. You can
   enable only one variant. If set more last disable other
   By default enabled -eof_lf if input no have '\n' in line end
   force added '\n' in last input data. Use -dn for disable it

   -eol_lf        Enable check end of line and force set LF == '\n'
                  if input have '\r' or '\r\n' this option
                  change it to single '\n'. (*nix way)

   -eol_cr        Enable check end of line and force set CR == '\r'
                  if input have '\n' or '\r\n' this option
                  change it to single '\r'. (old osx way)

   -eol_crlf      Enable check end of line and force set CRLF == '\r\n'
                  if input have '\n' or '\r' this option change
                  it to two end of line symbols '\r\n'. (windows way)

   Some brainfuck programs expect different behavior for end of file
   some expect write '0' in memory cell, some need save cell value
   and skip write other value in cell and some needed write -1 in cell
   Options bottom can enable one of varians. By default enabled -eol_zero
   You can enable only one varian. If set more last disable other.

    -eof_zero      If no have data to read, write 0 in memory cell m[i]=0

    -eof_eof       If no have data to read, write -1 in memory cell m[i]=-1

    -eof_skip      if no have data save cell value m[i]=m[i] (it like clamp)

    -eof_same      same as -eof_skip, just alias, it's easier to remember :)

Тут все хвалятся, а ййяяяааа написах браинфук интерпреатор в 200 байт! А ййя в три строчки.

А я в 1200+ говнострок модуля Lua + 500+ утилиты командной строки. Я конечно говнокодер тот ещё. Но всё же. Всякую херню учитывать приходится то там то сям, буквально на ровном месте. :(

Бесит блин :)

Можно ли в ядро linux впилить работу с путями по другому символу? насколько это сложно?

Можно. Очень легко. Просто заменить слеш на любой другой однобайтный в исходниках, внезапно. Но ЗАЧЕМ?

Естественно, пути со слешами работать перестанут, как и все программы, полагающиеся на них. Но можно и легко.

Просто заменить слеш на любой другой однобайтный в исходниках

Ньет, мне хочется символ из своей кодировки. Там он для разнообразия не будет однобайтным.

Но ЗАЧЕМ?

Чтобы API ядра стал более правильно спроектирован.

Ньет, мне хочется символ из своей кодировки. Там он для разнообразия не будет однобайтным.

Тоже можно. Будет сложнее и сломается ещё больше всего. И ненужность поделия повысится ещё на один порядок. Но, конечно, можно. И не то чтобы прям так уж сложно.

Чтобы API ядра стал более правильно спроектирован.

🤡

Зачем вообще ядро парсит строки? Сложно было массив массивов сразу в спецификации прописать?

Мне, кстати, ещё не ясно, почему есть разница в передаче параметров - в винде командная строка это одна строка, а в линуксе - массив строк, где один параметр может передаваться несколькими кусками.

Сделали бы единообразно - чтобы и пути тоже кусками передавались. А то тут так, там эдак…

Зачем вообще ядро парсит строки?

Тебе весь тред пытаются объяснить, что оно их не парсит. Почти. Для регистронезависимых ФС приходится.

Сложно было массив массивов сразу в спецификации прописать?

Да, сложно. Зачем усложнять, если можно не усложнять?

Для ядра имя файла это просто набор байт

Не всегда. К примеру в ZFS есть опция utf8only, которая проверяет, что этот набор байтов является валидной UTF-8 строкой.

Так мы выяснили факт, что
ядро разбивает пути по слешам или нет?
Если да, значит парсит. И слеш точка. «Чуть-чуть» считается!

Не на то сообщение ответил? Это не моя цитата. Наверное имелось в виду сюда: Как в ядро Linux передаются строки? (комментарий)

Процитировал криво, но в твоём сообщении суть та же - что ядру пофиг. В целом - да, пофиг, но есть ситуации, когда не пофиг.

есть ситуации, когда не пофиг

Это значит - ядру не пофиг. Это значит, что ядро является инструментом влияния и искоренения русских людей путём переучивания на английский язык.

В целом - да, пофиг, но есть ситуации, когда не пофиг.

Ну да. Но в моём сообщении примерно так и написано в принципе. С «это касается только ФС». То есть, что не во всех ситуациях пофиг. Про эту опцию у ZFS я не знал, кстати, поэтому привёл как пример регистронезависимые имена файлов — там тоже надо понимать кодировку.

Ну и ZFS не часть ядра Linux так-то ;) Сторонних модулей, где будут парситься строки и делаться сколько угодно всякого разного ещё, можно сколько угодно понаписать ;)

Ладно. Не буду больше кормить тролля. Ответы на свои технические вопросы ты вроде более-менее получил, и ладно.

что-то вспомнилось, что в апи вин32 все функции, принимающие строки, существуют в трех экземплярах: CreateProcessA принимает char*, CreateProcessW принимает wchar*, CreateProcess принимает макрос TEXT(), которым можно оборачивать и то и другое;

Кажется, кому-то хочется чтобы и в онтопик навалили такого счастья)) (переписанного на расте. разумеется)

Чудак, зачем это в ядро тянуть, в glibc работу с локалью зачем то запихали я раз 5 ошибки ловил в разборе строк, недавно glibc+php знатная уязвимость какраз на разборе не валидного символа случилась. Толи дело musl там тупо строки это буфер заполненый байтами, и проблем нет.
Мне такого в ядре не надо.

ну и что, а в линусе есть библиотеки lib, lib32 и lib64

Я наоборот предлагаю вытащить из ядра парсинг путей файловой системы.