Marcin Hagmajer развивает библиотеку для работы с однобайтными кодировками на JS

malloc_usable_size()

Нет!

1. это вообще не часть языка, а низкоуровневая системная функция.

2. Она возвращает число больше чем выделено под полезную информацию.

Итого, массивов в куче нет.

Индусы из m$ — не повод разводить помойку. Вот тут, кстати, пишут что исправили. Любое deprecated-дерьмище должно конвертироваться в нормальный формат при первом же поступлении, а не тянуть за собой гниль.

но выбор кодировки в диалоге сохранения есть же

Выкидывать выбор — последнее дело. Вопрос в дефолтах.

конвертироваться в нормальный формат при первом же поступлении

Так ведь сабж для этого и нужен. Чего визжишь?

Тем не менее, в самом языке массивы есть. Именно поэтому программы на Си могут работать с массивами хоть в куче, хоть не в куче. А где именно реализованы соответствующие инструменты - это уже дело десятое. Это unixway. В базе минимум, а дальше подключаются расширения с нужным функционалом по необходимости.

Она возвращает число больше чем выделено под полезную информацию

Это считается при заполнении выделенного массива. Или путём перебора до условного конца (например, '\0').

Но, с юникодом это так с ходу не сработает из за модификаторов.

работать с массивами хоть в куче, хоть не в куче

Ты упорот? Я тебе только-что доказал что массивов вне стека нет из за того что размер неизвестен, а он опять за старое.

Или путём перебора до условного конца (например, '\0').

А сложность сего действа O(n) а не O(1) — т.е. получаем ту же бодягу что с юникодом.

Но, с юникодом это так с ходу не сработает из за модификаторов.

Ну поясни. Вот, например:

size_t utf8len(const char* str){
	size_t len = 0;
	for(char* s = (char*)str; *s; s++){
		if ((*s & 0xC0) != 0x80) len++;
	} return len;
}
void foo(char* s){
	size_t nbytes = strlen(s);
	size_t nsymb = utf8len(s);
	cout<<"\""<<s<<"\": "<<nsymb<<" symbols ("<<nbytes<<" bytes)"<<endl;
}
int main(int argc, char **argv)
{
	foo("J");
	foo("Ж");
	foo("Ç");
	foo("⺟");
	foo("𠜎");
	return 0;
}

"J": 1 symbols (1 bytes)
"Ж": 1 symbols (2 bytes)
"Ç": 1 symbols (2 bytes)
"⺟": 1 symbols (3 bytes)
"𠜎": 1 symbols (4 bytes)

Так ведь сабж для этого и нужен.

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

Он и с хрюникодом работает же.

Я не вижу его в списке поддерживаемых кодировок.

Зато я вижу его в примерах.

массивов вне стека нет из за того что размер неизвестен

> cat ./mallocarraytest.c
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>

int main(){
        char *t;
        int i, n;
        t = malloc(40);
        n = (int) malloc_usable_size(t);
        printf("%d\n", n);
        for(i=0;i<n;i++)t[i]=75;
        for(i=0;i<n;i++)putchar(t[i]);
        free(t);
        putchar(10);
        return 0;
}
> gcc -o mallocarraytest mallocarraytest.c
> ./mallocarraytest
40
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
>

Как видно, всё есть. Вот работа с массивом:

       for(i=0;i<n;i++)t[i]=75;
       for(i=0;i<n;i++)putchar(t[i]);

       n = (int) malloc_usable_size(t);
       printf("%d\n", n);

40

Корректно возвращает

Где модификаторы?

Специально подбирал цифорку? А теперь осознай, что память выделяется блоками и в общем случае k!=n:

for(k=20; k<100; k++){
	t = malloc(k);
	n = (int) malloc_usable_size(t);
	printf("k=%d; n=%d\n", k, n);
	free(t);
}

Вот известен его размер

НЕ_ИЗВЕСТЕН, бл-дь! Там больше чем заложено, и дальше k лежит мусор. Это вообще системно-зависимая функция, а не часть языка. Читай http://www.slac.stanford.edu/comp/unix/package/rtems/doc/html/libc/libc.info.....

Где модификаторы?

Ну дай пример строки, или что ты под этим словом подразумеваешь. Я нашёл только https://www.w3schools.com/charsets/ref_utf_modifiers.asp.

Да, блоками. Но, функция malloc_usable_size() специально так сделана, что возвращает __юзабельный__ размер массива в байтах:

The  malloc_usable_size() function returns the number of usable bytes in the block pointed to by ptr

что ты под этим словом подразумеваешь

https://en.wikipedia.org/wiki/Combining_character , https://www.compart.com/en/unicode/combining , https://blogs.msdn.microsoft.com/shawnste/2010/01/25/most-combining-character... .

На пример по последней ссылке приведённый выше код, ожидаемо, говорит

9 symbols (27 bytes)

1 symbols (27 bytes)

И ты не прав. Всё сложней. Если в тексте обнаруживаются символы юникода, то нотепад предлагает сохранить в юникоде (UTF-16 двух видов, UTF-8). А остальной простой текст в однобайтовой кодировке (1251).

__юзабельный__ размер массива в байтах:

В дурочку не играй. Это не размер массива, а функция — не часть языка.

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

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

В то время как надо

Символов 9, знакоместо одно. А со знакоместами и размер TABов и шрифт и пр надо учитывать.

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

Ещё один ретроград.

на JS

Эти, конечно, поехавшие, но настолько... Это уже на 0.8 поттеринга тянет, не меньше.

Это не размер массива, а функция — не часть языка

Тем не менее, работа с массивами - часть языка, и оно доступно через API массива:

        for(i=0;i<n;i++)t[i]=75;
        for(i=0;i<n;i++)putchar(t[i]);

если уж требуется политеральная работа со сложными текстами

Что значит «требуется»? Бывает, конечно, заранее известно, что вот этот вот код будет работать только с вот такими конкретными случаями, где нет комбинированных символов. Однако, сказать что такой код поддерживает __весь юникод__ нельзя. А для того, чтобы поддерживать __всю ту или иную однобайтную кодировку__ никаких специальных плясок не надо.

Символов 9, знакоместо одно

Это __комбинированный__ символ из 9-ти. Юникод - он такой.

Английского и ASCII хватит всем.

A po4emu tbI eto na kirillitce pishesh? TbI sovsem poehavshiy ili uda4no pritvorjajeshsya?

Because I have cyrillic chars, of course.

Ну и правила форума такие, да.

и оно доступно через API массива

В куче нет никакого API массива; xs[ i ] — это то же самое, что *(xs+i), и никакого надёжного способа узнать сколько было выделено ячеек нет.

Что значит «требуется»?

То, что посимвольный/политеральный анализ требуется только для графического представления, и давно уже реализован в соответствующих библиотеках. Обычная работа со строками — это склейка, сборка-разборка и поиск паттернов, и кодировка вообще не играет роли. А посимвольный разбор — этов сегда O(n), а не O(1). Ты мне так и не смог привести практической задачи, где можно работать со строками за O(1).

But you say, that English and ASCII - is all that we need. If you are use cyrillic symbols - so, your needs are not satisfied by this character sets

Такие как он — это люди в стиле «а зачем в туалет идти, когда можно вот тут в парке под кустиком нагадить».

Я говорил про интерфейсы и локализацию.

Зачем локализация? Английского и ASCII хватит всем.

А теперь внимание. Только со стула постарайся не упасть. Готов? Не все знают английский, представляешь? А те, кто знают - не всегда хотят работать с английским интерфейсом.

К выделяемому функцией malloc() можно и нужно обращаться через API массива:

        t = malloc(40);
...
        for(i=0;i<n;i++)t[i]=75;
        for(i=0;i<n;i++)putchar(t[i]);

никакого надёжного способа узнать сколько было выделено ячеек нет

Зато есть надёжный способ узнать сколько было выделено байт:

n = (int) malloc_usable_size(t);

То, что посимвольный/политеральный анализ требуется только для графического представления

Как без него хотя бы узнать сколько символов в строке?

Про это уже была не так давно тема. Вот она: Зачем ставят локализованные версии ПО и софта? .

Что же касается второй части, то, внезапно, опять не все замечают, что «хватит всем» я взял из «640 Кб хватит всем».

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

Только это всё в той параллельной вселенной.

Тем не менее, в самом языке массивы есть. Именно поэтому программы на Си могут работать с массивами хоть в куче, хоть не в куче. А где именно реализованы соответствующие инструменты - это уже дело десятое. Это unixway.

Тут это скорее костыли, а не unixway. А то так можно договориться до того, что C поддерживает функциональное программирование.

Символов как раз 9. Просто отображаются как один. Для удобства пользователя те же текстовые редакторы также как один эти символы предоставляют.

У всех разные представления о том, что является костылями, а что - нет. unixway же о том, что каждая сущность занимается своим делом. От языка Си синтаксис обращения к массивам через индекс элемента в квадратных скобках, от glibc'а динамические массивы через malloc() и malloc_usable_size().

Так можно договориться и до того, что и все остальные комбинированные символы - это 2-N символов, а не один. Но, в том и заключаются претензии к юникоду сторонников однобайтных кодировок, включая Antonio Diaz Diaz'а из проекта GNU, что:

UTF-8 is fine for non-parsable, non-searchable documents that must look
"pretty", but not so fine for things like configuration files or C++
source code. UTF-8 greatly hinders parsability (and may even become a
security risk) by providing multiple similar-looking variations of basic
alphabetic, punctuation, and quoting characters. UTF-8 also makes search
difficult and unreliable. For example, searching for a word like "file"
in an UTF-8 document may fail if the document uses the compound
character 'fi' instead of the string "fi".

Зато есть надёжный способ узнать сколько было выделено байт
Как без него хотя бы узнать сколько символов в строке?

Я тебе битый день объяснял всё, да только как о стенку горох. Лети в игнор.

Так в случае однобайтных кодировок длина строки ни разу не определяется размером массива типа char. Для этого есть однобайтная функция strlen(), работа которой основана на подсчёте элементов массива до '\0'. Буфер под строку может быть какой угодно, это не значит что он до краёв забит строкой, и по его размерам нужно узнавать размеры строки.

работа которой основана на подсчёте элементов массива до '\0'.

ну вот хоть сам уже признал. Собственно именно об этом thunar и говорил:

А сложность сего действа O(n) а не O(1) — т.е. получаем ту же бодягу что с юникодом.

Я говорил, что этот же самый метод с юникодом не работает даже в случае wchar_t из за модификаторов (см. выше). А в случае с char и подавно. Т.е. и в случае char можно перебрать по code point'у, но при этом надо ещё понять какие из них образуют комбинированные символы. А в случае однобайтной кодировки достаточно посчитать кол-во элементов массива.

Это проблема виндузятников

Правда? KOIR-8r .......

ещё понять какие из них образуют комбинированные символы

решается парой строк кода, а сложность как была O(n) так и остаётся.

решается парой строк кода

Если задействовать внешние библиотеки наподобие icu. А если нет, то это совсем не пара строчек, поскольку тут и свои таблицы модификаторов, и учитывание особенностей комбинирования символов.

адействовать внешние библиотеки

О. МОЙ. БОГ!

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

Правда? KOIR-8r .......

Че сказать-то хотел?

Че сказать-то хотел?

Я хотел намекнуть что это проблема не только виндусятников, а вообще всех.На примере всего семейства KOIR-8.

Так KOI8-R - это не проблема. KOI8-R - это решение проблем (с модификаторами и комбинированными символами, разным весом разных символов в байтах,...).

Я хотел намекнуть что это проблема не только виндусятников, а вообще всех

Ты перед тем как попытаться «намекнуть» разобрался бы в вопросе чтобы свою тупость не рекламировать.

Во первых - при чем тут KOIR-8?

Во вторых - в какой кодировке в 2017 году сохраняются txt в линуксе, в маке, в андроиде, в ойфоне и т.д.? А в какой в винде?