Какой нативный тип данных для строк в линукс?

именно что «куча функций». и все они разные и несовместимые. потому я и говорю, что есть данные. а уж как их интерпретировать - дело частное.

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

а так-то сишечка работает и на микроконтроллерах, где никакого строкового вывода нет вообще и функций таких нет, соответственно.

дык и данных нет без интерпретации

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

иначе белый шум тоже данные.

да, белый шум - тоже данные. и если у тебя нет интерпретатора, то любые данные - это некие последовательности байтов, не несущие никакого смысла.

поэтому, кстати, тут многие не любят utf-8. он требует чуть больше шевелений задницей, чтобы с ним работать.

Вопрос неправильно сформулирован. Кодировка является не единственным признаком, характеризующим тип строки. Для типа строки может быть важным следующее: хранится ли информация о длине строки, какого максимального размера может быть строка, заканчивается ли она нулем, есть ли ограничения на ее содержание, можно ли изменить непосредственно саму строку и увеличить ее размер.

поэтому, кстати, тут многие не любят utf-8. он требует чуть больше шевелений задницей, чтобы с ним работать.

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

utf-8 именно так и был задуман англоязычными

Но ведь проблема не этом. А в том, что графика человеческих языков формализуется не так просто, как хотелось бы. И одна из причин, почему английский язык стандарт де факто в мире - его простая графика.

Вот кстати, голос разума. Тут как пошла пьянка про юникод, так не заткнуть фонтан. А реально критичным является

хранится ли информация о длине строки

В тему, https://www.joelonsoftware.com/2001/12/11/back-to-basics/

Наверное всё-таки

Мы не будем переписывать большое кол-во ASCII-only кода

а не

нам пофиг ваши туземные проблемы с вашими недоязыками

Если нет, продолжение разоблачения в студию

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

Да ладно. Типичная англофилия. Не было б скученной агресивности в Европе с этими мировыми войнами, мог и немецко-французкий быть основным. Когда коммунист Миттеран порвал с НАТО, иностранная переписка на конвертах писалась либо транслитом для всяких там поляков либо на французком. До WWII - на немецком. Помните, «набираю я диск телефона это вечное 07» Высоцкого? Он в Париж жене звонил.

Наверное всё-таки

Нет. Имеено что «мы и будет дальше писать ascii-only, даже с ошибками 7-8 signed/unsigned, ибо от таких ошибок даже протестировать нам проблематично».

Был бы английский со сложной графикой, в основе utf8 не было бы полноценного такого «английского» алфавита. Точно тебе говорю :)

ну, был вариант занять первенство в IT и установить гегемонию. кто мешал-то? но нет же, наши поцреоты могут только бздеть, что их абидели проклятые капиталисты. радуйтесь, что люди, которым русский (равно как и куча других языков) никуда не упёрлись, вообще всё это поддерживают. могли бы и забить нафиг.

о нет же, наши поцреоты могут только бздеть,

Наши патриоты изобрели как и все неироглиграфические свои koi8-r и не бздят. Бздят как раз вот такие, которые нихрена не поняли, о чём было сказано, но похамить хочется.

никуда не упёрлись, вообще всё это поддерживают. могли бы и забить нафиг.

Именно, что кинули кость в виде utf-8 и забили, спихнув и дальше всю интернационализацию на тех, кому это «надо». Типа мы тут ядро пишем, а вы можете нам не мешая копаться в этом многобайтном дерьме.

Типа мы тут ядро пишем, а вы можете нам не мешая копаться в этом многобайтном дерьме.

и абсолютно правильно. проблемы кодировок шерифа не беспокоят. напишите своё ядро и там хоть на ушах стойте.

и абсолютно правильно. проблемы кодировок шерифа не беспокоят. напишите своё ядро и там хоть на ушах стойте.

Вот видите, именно это я и сказал в первом моём коментарии в этом топике, на который вы в начале бросились хамски опровергать, а теперь полностью подтвердили, думая, что выглядите умно.

так я ничего и не опровергаю, кроме глупых притязаний на чужое добро. хотите свои кои - пишите свою ось. слабо? сидите ровно и не жужжите.

так я ничего и не опровергаю, кроме глупых притязаний на чужое добро. хотите свои кои - пишите свою ось. слабо? сидите ровно и не жужжите.

Меня вполне устраивало чужое добро, которое прекрасно работает с koi8-r. Да, иногда приходится поправлять авторов, пока это не выходит из привычного им 8-битового мира эти правки по обычным им ошибкам 7-8 signed/unsigned они без проблем принимают.

сидите ровно и не жужжите.

Я вот для себя понял, почему в русском сегменте такой вечный срач и нет пророка в своём отечестве. Потому что по определению считают, что все неаглоязычные в принципе не могут что-то дельное и правильное сказать, и даже не разбираясь и не вникая, надо броситься опровергать, хамить и не соглашаться. Хотя глупости от ТУДА ровно столько же.

а что вникать-то? неосиляторы utf-a плачутся, что их абидели. все дети детятся на тех, кто решает проблемы и тех, кто бежит к мамке плакаться. и потом вырастают такие же сопливые взрослые с вечным нудением про то, что им что-то недодали. я часто вижу второй вариант. но я отношусь к первому. отсюда радикальное непонимание.

весь этот плач и псевдопатриотизм скрывает под собой банальное неосиляторство. вот и всё.

не будут работать операции со строками из стандартной библиотеки, причём некоторые, включая наиболее важные printf и конкатенацию таки будут

Вот кстати, голос разума. Тут как пошла пьянка про юникод, так не заткнуть фонтан. А реально критичным является

хранится ли информация о длине строки

Я уже давно даже на Си явно передаю длину строки, будь то в составе структуры или отдельным аргументом. Нужно понимать, что Томпсон, Кэрниган, и Ритчи были хорошими кодерами, но далеко не самыми лучшими архитекторами. Юникс изначально была очень примитивной однозадачная система на асме:
https://en.wikipedia.org/wiki/Unix#History
Причем, остатки однозадачности дожили до наших дней, например, в виде fork-а. Можно ли оправдать такое решение на фоне того, что первый многопоточный процессор был еще в 1963 году, а юникс выпущен в 1973? Не знаю, сами придумывайте ответ.
Впоследствии ее переписали на близком к асму наспех состряпанном языке. Создателям юникса, да и много кому в то время показалось быстрее и проще сделать строки без числа символов, чтобы можно было двигать указатели, не занимаясь превращениями длин строк в длины подстрок - так все делают, так буду делать и я, я так привык. Традиция необучаемости продержалась у многих фанатов C и шелла до наших дней, к слову.
Паскаль! Первый паскаль, выпущенный в 1970 году, уже не имел проблемы с длиной строк - она хранилась перед строкой, а нулевого терминатора не было вообще. И, тем не менее, в 1973 году Си выходит с теми самыми строками, которые дожили до наших дней.
Если вы до сих пор используете такие строки, то можете винить только себя. По поводу 1973 года я напомню, что это годы кризиса после дефолта США 1971 года, когда лишних ресурсов не было, когда коммерсам компьютеры еще не были нужны, потому что они были дорогие и слабые - только в конце 70-х/начале 80-х коммерциализировалась отрасль, возникли юниксы с закрытыми исходниками, возник MS DOS. До этого софт разрабатывался в основном государством, в частности, военкой и институтами на грантах. Когда семидесятые прошли, то возникла ситуация «вы можете написать ОС лучше, но у нас она уже есть и ею много кто пользуется». Аналогичная ситуация возникла в этой связи с C++ и Objective C.
А вот позже, в середине-конце 80-х годов у Plan 9, писанный группой людей близкой к разработке исходного Unix, уже имелись строки с явной длиной:
http://man.cat-v.org/plan_9/2/string
И где сейчас Plan 9?
В винде строки явной длины появились где-то в районе NT 4.0 с появлением COM и SysAllocString/SysAllocStringLen, которое выделяло юникодную строку с сохранением длины строки перед первым символом. По крайней мере в NT 3.1 этих механизмов точно нет, про NT 3.5 не скажу - так что где-то 1995-1996 год, заметно позже Plan 9. Как и в Plan 9, этот подход решал большую часть проблем возврата строки неизвестной длины, поскольку всё выделение и высвобождение велось через одну и ту же функцию, а длина выделенной памяти всегда была известна.

utf-8 именно так и был задуман англоязычными, что нам пофиг ваши туземные проблемы с вашими недоязыками, мы и дальше будем работать, скажем в ядре, с байтами, а вот вам поддержка всех ваших папуаских алфавитов, вот сами их и поддерживайте как можете и отстаньте от нас

Софт в основном разрабатывался и использовался в США. А вот софт, который разрабатывался в СССР, имел только кириллицу и не поддерживал латиницу. Сегодня кто-то может не поверить, но это было так - первые 127 байт использовались под кириллицу. Не весь софт был такой, но он такой был. В итоге кто победил - тот и прав, теперь все жрите латиницу.

Имеено что «мы и будет дальше писать ascii-only, даже с ошибками 7-8 signed/unsigned, ибо от таких ошибок даже протестировать нам проблематично»

Да ладно тебе, всё они могли протестировать - просто не хотели. Любые символы бери под вторые 128 байт, и тестируй. Но они не будут этого делать.

Софт в основном разрабатывался и использовался в США. А вот софт, который разрабатывался в СССР, имел только кириллицу и не поддерживал латиницу. Сегодня кто-то может не поверить, но это было так - первые 127 байт использовались под кириллицу. Не весь софт был такой, но он такой был. В итоге кто победил - тот и прав, теперь все жрите латиницу.

Всё было гораздо сложнее и интереснее. Вот взять к примеру электропочту. Вначале было слово, 7 бит и uuencode для всего остального. Потом всякие с умляутами и прочими акцентами возмутились, ну какая вам нафиг разница, добавьте восьмой бит. И таки да, следующим этапом была почта без хидера кодировки и почтовики как могли распознавали содержимое и выводили как есть. Тогда и придумали koi8-r, ибо оно даже при глючной почты, кушающей 8-бит всё равно читалось. Тогда ещё СССР был, как щас помню. :) Потом пришёл utf-8. Думаете полегчало? Ага, щаз! Взяли и жестко прописали в стандарт, что кодировку то мы указывать обязаны, а вот 8-бит - фиг вам! Будем посылать либо в base64 либо в quote-printable, ибо ваши попуаские 8-биты у нас нифига не принтабле, мы разражаемся, если их видим, чинить не будем и идите в задницу.

А когда Юникод стал восьмибитным? Вроде же был двухбайтной кодировкой, а потом внезапно оказалось, что он UTF-8.

весь этот плач и псевдопатриотизм скрывает под собой банальное неосиляторство. вот и всё.

Вы о чём-то всё своём. Наверное вас какой-то патриот обидел. Наверное Чернов, подвигавший koi8 был не патриот, или таки патриот, потому что у вас это слово с отрицательной конотацией? Ну Ok, пусть я буду неосилятором, но зато удобно жить в своём мирке 8-битной кодировки, всё равно я кроме немецкого и английского и таджикского ничего не знаю, но надеюсь так и помереть без хрен-знает-сколько-байт-в-символе в текстах на моём диске и, о жесть, в продакшене, что мне приходится работать. Вы не в курсе, почему в названииях фирм в госбазах нельзя всякие кавычки ёлочки? Я вот думаю, потому что нафиг не надо и достаточно ". Путь будет патритичненько. Зато удобно и практичненько.

А когда Юникод стал восьмибитным? Вроде же был двухбайтной кодировкой

Юникод никогда не был битным. Юникод в самой простой интерпретации это пронумерованный список символов. Там и английские, и русские буквы, и иероглифы, и псевдографика, и смайлики, и вообще все символы, которые только нашли. Номер символа в этой огромной таблице называют кодовой точкой. Так любой текст представляется последовательностью кодовых точек.

Юникод — не кодировка.

Кодировка это такой способ представить кодовые точки в виде последовательности байт. UTF-32 — каждая кодовая точка переводится в четыре байта. UTF-16 — каждая кодовая точка переводится либо в два байта, либо в четыре байта. Большинство используемых кодовых точек представимо двумя байтами в UTF-16, но для некоторых всё же нужно четыре. UTF-8 — каждая кодовая точка представляется последовательностью от одного до четырёх байт. Вообще-то, до шести, но в Юникоде столько кодовых точек нет, поэтому пока что хватает четырёх.

Интересная терминология. В вики юзается вместо точки - позиция. Как-то звучит лучше. особенно подчеркивая, что позиция не должна быть без пропусков.

про ёлочки хз. я их не использую. это какая-то типографская дурь тут на ЛОРе. один из видов мелкого извращенства. но специально с ним бороться лень. в реальности, конечно, нет никаких ёлочек. есть одинарная и двойная кавычки.

« »

вах! оно воспртняло не так как я хотел!

для вас более реально, что в ascii-7 и менее реально что в utf-8 больше 1 байта.

реальность данная в очучениях имплицирует распределения осознаний

зы. [s]Картаго делинда[/s] ТСу - ну какое на данный момент(и/или) после) не менее общее решение ’«Какой нативный тип данных для строк в линукс?»` чем просто utf-8 "

иначе белый шум тоже данные.

а свободная энергия тоже энергия. которая связана и непонятно как из неё полезную работу получить :)) у Сета Ллойда «Программируем вселенную» про квантовый компьютер даже приблизительный расчёт какой-то есть, порядков свободная/связанная :)

да, в gnu вообще и в groff в частности любят всё усложнять, где не нужно. например, neatroff и утилиты или troff из plan9. гораздо прозрачнее код.

Побольше двух экранов, и поддерживает только HTML вывод:

ещё были makedoc3+litprog backend, сайт make-doc-pro и ещё что-то.

mdp умеет Latex формулы, в какой-то HTML+MathML. MD3 написан как литературная программа + конечный автомат с настраиваемыми бекендами, где-то рядом на том же сайте лежит генерация PDF на чистом реболе (150кб).

видел ещё какую-то версию под REBOL3, сейчас не вспомню.

оригинальный makedoc простой потому что это такой markdown простой. к чему усложнять.

собственно, примеры литературных программ. просто, понятно и прозрачно.

make doc pro правильная ссылка исходник

pdf-maker, pdf-maker-doc на чистом REBOL здесь

по ссылке оттуда: «better strings library» сравнение

хотите свои кои - пишите свою ось. слабо?

с ятями и ерами нужно, с фитою и ижецею. чтобы исконно, посконно и домотканно. дабы скрепы же.

все дети детятся на тех, кто решает проблемы и тех, кто бежит к мамке плакаться.

ну просто есть такие решения которые только всё усложняют. к примеру, почему в 80-90е было столько кириллических кодировок, и все разные? у одной старший бит красиво резался, что уже само по себе костыль, и буквы не по алфавиту. вторая iso которой никто не пользовался. и пара проприетарных.

сейчас у уникодных всё-таки недостатков в чём-то меньше (нет этих граблей), в чём-то больше (обрабатывать сложнее и медленее, да и те же составные символы например «й» из пары отдельных).

но да, заткнули проблему с иероглифами. пока не прилетят инопланетяне с нибиру с >2^32 символов.

в этом смысле utf8 из plan9 – это да, умный хак. чтобы англоязычное ascii по минимуму переделывать пришлось. а какой-нибудь 32-битный уникод оверинжиниринг для нибиру.

юникод хорош тем, что ты не паришься в разработке насчёт языков. хоть китайский. при этом для девелопера абсолютно до фени. какая там страница. и можно комбинировать текст из разных символов без проблем. что сразу решает вопросы с i18n. я ещё давно перешла на utf-8, ещё когда под маздай писала. потому что это решает сразу много проблем, а накладные расходы минимальны. работа с текстом никогда не была быстрой и, главное, что там это и не нужно особо: это, как правило, не риалтайм, а где риалтайм - там бинарные данные. тем более, что сейчас есть icu и вообще проблем с перекодировками нет никаких.

напишите своё ядро и там хоть на ушах стойте.

При чём тут ядро? Оно актуально только для вывода текста в ядерной консоли. Но ядро Linux в этом смысле и так поддерживает хоть UTF-8, хоть однобайтные кодировки. Кому какой режим нужен - тот и включается.

Самая суть поддержки кодировок при написании софта на Си - это поддержка этих кодировок в glibc. Классические строковые функции в glibc оставлены однобайтными, работающими с char *. Для многобайтных строк в glibc внедрили wchar_t и новые многобайтные функции, которые работают с wchar_t *. А всякие icu и прочее - это уже дополнительные библиотеки, которые не относятся к glibc.

А всякие icu и прочее - это уже дополнительные библиотеки, которые не относятся к glibc

Пруф?

http://site.icu-project.org/download

Это совсем не gnu.org. А вот glibc разрабатывают как часть проекта GNU - https://www.gnu.org/software/libc/ .

И где сейчас Plan 9?

где-то здесь, здесь и здесь и книжка по inferno -

и кстати, troff уникодопрозрачный + eqn + тот же plot из исходников доки в *.ms генерируют нормальные уникодные *.ps, *.pdf. и postscript

вот могут же, если захотят? почему в линуксе всё всегда с костылями – или ghostscript без кириллических шрифтов, или LaTeX правильный, корректный результат ценой 4 Гб или groff со скриптами для уникода (MOM или как-то так – а без результат непредсказуем или долго нужно читать доку на troff), или компактный lout, но закат солнца вручную? хотя вот pandoc например просто работает.

прям целый квест нужно пройти, наступая на все грабли – просто чтобы научиться создавать *.ps или *.pdf с русскими буквами. а не просто работает по дефолту, как и должно быть (пусть даже из-за какой-то магии и хитрых конфигов).

вопрос риторический, конечно.

полезно различать синонимы

т.е симетричаная разность синонимом желательно не равна обоим разностям в отдельности.

поэтому желательно различать данные и информация и удобно иметь области узкого значения в которых данные не значат информация и информация не значит данные

иначе тавтологичней

между 1917 и 1956 были чорт и итти - эволюция не тождественна прогрессу

…

https://en.wikipedia.org/wiki/Worse_is_better

есть стандарты и есть реализации. надо их различать. glibc - одна из реализаций. причём не самая лучшая в плане поддержки стандартов, если уж на то пошло. там много рудиментов, а также нестандартных расширений.

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

32-битный я не видела нигде, кроме как у китайцев. у них язык такой жуткий, что не хватает им нормальных символов. как там у них обстоят дела с мультибайтом - я хз. но какие-то иероглифы у меня в utf-8 отображаются. возможно, что не все возможные. тут я не спец.