libmui — библиотека для интерфейсов в стиле MacOS Classic

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

И VLA это далеко не единственный бред, который выдумали сумасшедшие стандартизаторы C99.

И VLA это далеко не единственный бред

А чем они так плохи? Вроде бы мелочёвка ничего особо не усложняющая ни в компиляторе, ни в компилируемых программах.

Есть секта батхертеров.

Есть секта батхертеров.

Главное, не говорить им, что это буквально вызов alloca(), завёрнутый в синтаксис.

Где-то я видел ссылку на то, что «в отличие от alloca(), VLA considered harmful» и объяснение на много букв. Но так как мне было лень читать, то так и остался непросвященным.

Ну там главная тема в том, что с alloca() ты можешь сделать вот такой трюк:

void f(size_t n) {
  void *ptr = n < TOO_BIG_FOR_STACK
            ? alloca(n)
            : malloc(n);
  
  ...

  if(n >= TOO_BIG_FOR_STACK)
    free(ptr);
}

Для маленьких кусков данных получишь прирост к скорости за счёт размещения на стеке, но при этом не просрёшь его, если данных много. С VLA такое не канает.

На самом деле VLA расширяет систему типов, массив на стеке там побочное явление. Более того, то, что он на стеке, это вина разработчиков GCC.

Загуглил. https://habr.com/ru/articles/681312/

Интересно.

void baz(int a[printf(«Hello World\n»)]) {}

В данном примере каждый вызов функции baz будет сопровождаться выводом строки «Hello World\n».

Оооо… я прямо предвкушаю в Development вагоны отстреленных ног и очереди из разорванных жоп сишников, которые случайно вот это задействуют.

Ага. Ну и как работает следующий код?

struct Some
{
  int a;
  char b[];
};

Ага. Тип, размер которого не известен на момент компиляции. Действительно, ничего не усложняет...

Ага. Тип, размер которого не известен на момент компиляции. Действительно, ничего не усложняет…

Так да, не усложняет. Тебе void *ptr в каждом втором интерфейсе же не усложняет? Почему vla должен?

Потому что это невозможно отлаживать. И вместо явного выделения на стеке через alloca появилось неявное.

От того что ты миллион раз это повторишь, оно понятнее не станет. Чем это от void *ptr с точки зрения отладки отличается?

void * имеет понятный размер и предсказуемое поведение. Собственно он может либо указывать на сущность, либо на 0, либо на сущность, которой более не существует.

Какой бесполезный ответ. За void *ptr прячется нечто, вычисляемое в рантайме. Более того, в зависимости от внешних условий там может быть struct *foo или struct *bar. Все ядро на этом построено, например. Или плагины в nginx. И ничо, никто не умер.

Обычно void * используется для того, чтобы «пробросить» через какое-нибудь API указатель. Т.е. функция имеет вид void f (void *), потому что какой-то библиотеке надо получить указатель вида void (ptr*)(void*). При этом сама пользовательская функция внутри себя обратно кастует void * к указателю на нужный тип.

Обычно void * используется для того, чтобы «пробросить» через какое-нибудь API указатель. Т.е. функция имеет вид void f (void ), потому что какой-то библиотеке надо получить указатель вида void (ptr)(void*). При этом сама пользовательская функция внутри себя обратно кастует void * к указателю на нужный тип.

Да. Ты обдолбался и получил сегфолт, потому что скастовал не в ту структуру. Твои действия? Чем это отличается от того, что ты обдолбался и неправильный размер VLA массива использовал?

Кстати, это вроде UB. Т.е. может произойти что угодно.

Ошибиться с VLA очень легко. Ошибиться с кастом указателя намного сложнее. Ты хочешь, чтобы функция получала struct Some *, поэтому пишешь void * и в первой же строчке обратно к struct Some * приводишь.

Кстати, это вроде UB. Т.е. может произойти что угодно.

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

Ошибиться с VLA очень легко.

Не сложнее чем с обычным массивом. И не легче. Буквально так же.

Ошибиться с кастом указателя намного сложнее.

Ахаахахаха. Нет.

Ты хочешь, чтобы функция получала struct Some *, поэтому пишешь void * и в первой же строчке обратно к struct Some * приводишь.

А ещё ты проверяешь границы буфера и не выходишь за него. И use-after-free не делаешь. И много чего ещё. Все эти ошибки прекрасно дебажатся с gdb, VLA тут вообще ничего не добавляет.

Ошибиться с VLA очень легко.

Млять, а с вызовом memcpy или malloc ошибиться сложнее??

malloc очень сложно вызвать. Надо указать размер в байтах и все... Ну и полученный указатель сравнить с нулем.

memcpy тоже очень сложно вызвать. Никто не справляется.

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

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

Это… основа, я бы сказал, база, сишного мирка. Никто не умеет безопасно писать на C. У всех когда-либо были тупые баги с off-by-one.

Что значит «безопасно»? Ошибки можно допустить везде. Покажите мне язык, где обращение к элементу массива за его границами не ведет к неопределенному поведению / исключению.

Что значит «безопасно»? Ошибки можно допустить везде. Покажите мне язык, где обращение к элементу массива за его границами не ведет к неопределенному поведению / исключению.

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

Фиг с ним. Давай следующую бредню из C99 разберем: strict aliasing.

Давай следующую бредню из C99 разберем: strict aliasing.

Точно из секты, я угадал.

Точно из секты, я угадал.

С этим он угадал. Его много кто выключает.

Зато бред про ололо компилятор компилит код как есть - шикарный)

Покажите мне язык, где обращение к элементу массива за его границами не ведет к неопределенному поведению / исключению.

Сотни их. Но это тут ни при чём.

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

Тот же вопрос про VLA.

Ну его даже gdb умеет, г-ди:

$ cat test.c                                       
#include <stdio.h>
#include <stdlib.h>

int
main(void)
{
	int n = 10;
	int a[n];

	printf("sizeof (a) = %zu\n", sizeof(a));
	abort();
	return 0;
}
$ gcc -std=c11 -ggdb -o test test.c
$ ./test 
sizeof (a) = 40
zsh: IOT instruction (core dumped)  ./test
$ coredumpctl debug -A "-batch -ex 'frame 3' -ex 'print a'" 
[...]
Program terminated with signal SIGABRT, Aborted.
#0  0x00007ba239a6f32c in ?? () from /usr/lib/libc.so.6
#3  0x00005ab569f251d6 in main () at test.c:11
11		abort();
$1 = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

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

Мы, напомню, про C. Это случится в любом случае и VLA тебе уже хуже не сделает.

Сделает. Когда у вас структура неизвестного размера с абы какими данными понять, где именно случилось проблема очень сложно, ведь она случается в РАНТАЙМЕ! Причем средств для диагностирования этих проблем просто нет.

Когда у вас структура неизвестного размера с абы какими данными понять, где именно случилось проблема очень сложно, ведь она случается в РАНТАЙМЕ!

А это и без VLA можно делать. Например, частая тема:

struct s {
  size_t sz;
  char data[];
};

struct s* alloc_s(size_t sz) {
  struct s *s = malloc(sz + sizeof(struct s));
  if(s != nullptr)
    s->sz = sz;
  return s;
}

Такое уже лет 20 существует.

UPD:

Ага. Ну и как работает следующий код?

лол хайвмайнд! Отлично работает следующий код :DDD

А это и без VLA можно делать. Например, частая тема:

Только не char data[], а char *data.

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

Да нет, он все правильно написал.

Нет, не правильно. В «замечательном» C99 char data[] в структуре означает, что массив будет иметь такой размер, какой получится в результате его инициализации.

Ты путаешь vla и flexible array member.

VLA про то, что sizeof не сможет ничего сказать про struct Some в compile time.

И чо?

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

Ну, да. Всё так. А что плохого-то? В гнутом говне это ещё до C99 ёмнип появилось, только там надо было 0 в объявлении структуры писать.

https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

0 в объявлении структуры писать.

Это другая штука.

VLA удобны тем, что ты можешь сделать функцию вида void foo(int n, char a[n]), и компилятор понимает, что n – это длина массива a. Не просто разраб понимает это тайное знание, но и компилятор.

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

Ещё немного и сишники изобретут параметрические типы. Они, собственно, в C уже давно есть на уровне компилятора, просто свои делать нельзя.

Компилятор не должен ничего понимать. «Си — это кроссплатформенный ассемблер». В цели этого языка не входит предоставление высокоуровневых абстракций. Вы же не требуете аналогично, например, от FASM. Почему вы этого требуете от Си? Что вы написали, то он и сгенерировал. Если что-то не так с руками, то не надо заниматься деятельностью по «стандартизированию» Си, а надо чинить собственные руки.

Компилятор не должен ничего понимать. «Си — это кроссплатформенный ассемблер». В цели этого языка не входит предоставление высокоуровневых абстракций. Вы же не требуете аналогично, например, от FASM. Почему вы этого требуете от Си? Что вы написали, то он и сгенерировал. Если что-то не так с руками, то не надо заниматься деятельностью по «стандартизированию» Си, а надо чинить собственные руки.

А это вообще полный бред. В компиляторе C оптимизатор на два миллиона строк, C ОЧЕНЬ старается сгенерировать не то, что ты написал, а то, что будет быстрее работать.

О, «хакиры» из-под коряги вылезли.

Ты не из секты «UB не существует»?

Нет, я не против UB. Оптимизатор может делать что хочет, пока это не нарушает задумку автора. Как только он начинает требовать от программиста лишнего (вроде того же strict aliasing), он становится только вредным.

Компилятор компилирует не то, что ты ДУМАЕШЬ, что написал, а то, что ты написал по факту.

Он не доморощенный литературный критик на ютубе, чтобы раскрывать «задумки автора».

Отмазка реально звучит в стиле сектантов плоской Земли.

А как он может понимать, что я хочу сделать, например, работая с метками? Правильно, никак. И оптимизатор часто творит фигню. Хотя метки описаны очень подробно в стандарте от ISO.

Что вы написали, то он и сгенерировал.

АУЫАУАУАУАУААЫЫЫЫЫЫЫЫЫЫЫЫ

То-то блин в шланге с гцц по миллиону с лишним строк в каждом, которые делают просто чудовищные вещи с твоим сишным кодом.

В цели этого языка не входит предоставление высокоуровневых абстракций.

Только C это делает на каждый чих.

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

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

Без этой фигни ты бы не мог бегать и рассказывать всем, какой C быстрый. ПОтому что C с -O0 сливает даже голангу.

Таки основное отличие -O0 и -O1 - вовсе не в порче кода, данного программистом, а в отсутствии оверхеда, данного уже компилятором. Например, избавление от лишних стекфреймов, более адекватное засовывание переменных в регистры итд. Всякая дичь начинается в -O2 и ещё хуже в -O3. Хотя, в -O1 она тоже местами есть в последних версиях, но её влияние незначительно. И, что удивительно, хорошо написанный код имеет большую разницу по скорости между -O0 и -O1, незначительную а иногда и никакую между -O1 и -O2, а -O3 местаи вообще оказывается медленнее чем -O2. Так что, большинство этих переделываний - это попытки компилятора исправить чей-то некачественный код.

Так что, большинство этих переделываний - это попытки компилятора исправить чей-то некачественный код.

Прости, сегодня уже не могу воспринимать всерьез твои бредни, завтра еще раз попробую.

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

Их авторы реализуют стандарт языка. Причём с религиозным упорством. Соответственно, все вопросы к авторам этого стандарта.

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

Почему-то к спецификации ANSI вопросов ни у кого нет. Я ни разу не видел, чтобы кто-то заявлял, что ANSI C — плохая спецификация.

Почему-то к K&R спецификации тоже ни у кого вопросов нет. Опять-таки я никогда не видел критики в адрес K&R C.

Зато к деятельности ISO вопросов масса. Причем как у программистов Си, так и Си++.

Я не удивлюсь, если спецификацию Си, которую разработают пара-тройка ученых (вчерашних студентов) будет лучше, чем вся «продуктивная деятельность» ISO за последние 25 лет.

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

ISO не пишет стандарт C. Стандарт пишут чуваки из контор типа Гугеля или Микрософта.

Почему-то к спецификации ANSI вопросов ни у кого нет. Я ни разу не видел, чтобы кто-то заявлял, что ANSI C — плохая спецификация.

ANSI C – плохая спецификация, ведь именно в ней появился такой термин как UB.

Алсо, ANSI тоже не писали стандарт. Его писали чуваки из всяких AT&T и прочих IBM.

Почему-то к K&R спецификации тоже ни у кого вопросов нет. Опять-таки я никогда не видел критики в адрес K&R C.

K&R C – полное говно. А ещё, K&R C не является спецификацией.

K&R C – полное говно.

Конкретики не будет.

А ещё, K&R C не является спецификацией.

Это именно что спецификация, а не стандарт.

Конкретики не будет.

Конкретика: язык C как он описан в K&R был заточен под PDP-11 и на других платформах работает как говно. Поэтому в 80х разные конторы плодили компиляторы под свои платформы с вагонами расширений, чтобы это всё хоть как-то шевелилось.

Это именно что спецификация, а не стандарт.

Нет, это учебник.

Нет, это учебник.

Спецификацию от стандарта отличает как раз необязательность наличия статуса юридического документа.

Вообще плохо, когда стандарт пишет только одна организация. Нет желания написать его нормально (ведь и так сожрут, альтернатив ведь нет).

Лично я был бы всеми руками и ногами за, если был бы какой-нибудь ГОСТ на язык программирования Си (и Си++), который бы отличался от бредней ISO в лучшую сторону.

Спецификацию от стандарта отличает как раз необязательность наличия статуса юридического документа.

Нет, не отличает. У стандарта ISO нет никакого особого юридического статуса.

Вообще плохо, когда стандарт пишет только одна организация. Нет желания написать его нормально (ведь и так сожрут, альтернатив ведь нет).

Лол я тебе ещё раз объясняю, что ISO не пишет стандарты.

Лично я был бы всеми руками и ногами за, если был бы какой-нибудь ГОСТ на язык программирования Си (и Си++), который бы отличался от бредней ISO в лучшую сторону.

Только это будет не язык программирования Си. Это будет другой язык.

Только это будет не язык программирования Си. Это будет другой язык.

Почему же C99 считают языком Си? Авторы его не писали таким. Более того, они сами решительно выступали против ISO'шной самодеятельности. Они и против ANSI были, если честно, но все же согласились написать во втором издании именно про ANSI C. (Они были против слова const)

Почему же C99 считают языком Си? Авторы его не писали таким.

Да нет, авторы C99 писали C99 именно таким, каким они его написали.

Более того, они сами решительно выступали против ISO’шной самодеятельности.

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

Но если тебе хочется сишечку не от ISO, поставь себе kencc. Прямо от Кена Томпсона, как диды завещали. Только сишный код в лялексе им компилиться не будет.

Только это будет не язык программирования Си. Это будет другой язык.

Ещё как будет, если к нему сделают рабочий компилятор.

Спецификацию от стандарта отличает как раз необязательность наличия статуса юридического документа.

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

Лично я был бы всеми руками и ногами за, если был бы какой-нибудь ГОСТ на язык программирования Си (и Си++), который бы отличался от бредней ISO в лучшую сторону.

Вся это графомания, вне зависимости от авторства, никакой самоценности не имеет. Есть реальный компилятор, у него есть спецификация что именно он компилирует - вот это важно.

Нет, K&R плохой не из-за PDP, а из-за таких вещей как неявный int и указание типов аргументов отдельно от их списка, а так же ряда других на то момент не сильно сформировавшихся вещей, которые я не помню. В целом это всё не их вина, а просто язык был ещё недоработан.

И всё-таки K&R вполне можно считать спецификацией.

Нет, религиозное упорство тут у шланга. А gcc просто шлют юзеров в стандарт вместо посылания в другие места, когда не хотят отвечать на их багрепорты.

Какой в жопу VLA? C! CVE LANGUAGE! Ошибся в длине буфера переписал половину программы, не туда переменную поставил датагонку получил. Но нет, ВОТ С VLA-ТО НАЧНЕТСЯ.