Если вам не хватало UB в C, то вам принесли ещё

А существует C, отличный от C99?

А существует C, отличный от C99?

C11, C17. В c99 нет атомиков, например.

А существует C, отличный от C99?

The kernel is written in the C programming language [c-language]. More precisely, the kernel is typically compiled with gcc [gcc] under -std=gnu11

https://www.kernel.org/doc/html/latest/process/programming-language.html

Внесите Царя

ЯННП, кроме UB

Вот этот код может вернуть тебе не NULL:

void *resize_array(void *ptr, size_t n)
{
    ptr = realloc(ptr, n);
    if (n == 0) {
        errno = 0;
        return NULL;
    }
    if (ptr == NULL)
        errno = ENOMEM;
    return ptr;
}

Просто потому что компилятор знает, что n != 0 (потому что это UB), а значит эту ветку кода можно просто выкинуть!

тута - https://research.nccgroup.com/2020/04/09/c-language-standards-update-zero-size-reallocations-are-undefined-behavior/

Making this behavior undefined continues to allow existing implementations to do as they please, but provides a clear warning to developers to guard against zero-byte reallocations.

То есть тридцать лет спустя, имея постоянные проблемы с int overflow, до этих клоунов никак не дойдет, что silent UB – это источник багов?

Надо просто весь язык C сделать UB. Это позволит сократить стандарт до описания синтаксиса и строчки «behaviour of a valid C program is undefined».

Синтаксис это лишь вершина айсберга.
А далее: алгоритмы, логика, ...

Да-да, это всё UB будет. Как и завещали авторы стандарта.

Гм., всё продумано и от UB не убежишь.

Комитеты убивают языки, ничего нового.

Это ЗАГОВОР.
У них есть ЯП без UB и они его от нас его скрывают!

У них есть ЯП без UB и они его от нас его скрывают!

Почему скрывают? Rust.

Ты у меня так подписан:

cumvillain  фанат бюрократических си-стандартов https://www.linux.org.ru/forum/development/17122046

Что касается темы - то думаю всем будет плевать. Документация glibc имеет приоритет над любой графоманией (т.к. она, в отличие от графомании, первоисточник), ну а авторы gcc ни в коем случае не станут ломать glibc. Что касается шланга, то от них можно любой дури ожидать, но думаю у них хватит ума ничего не портить.

Впрочем, зачем делать realloc(0) я не знаю.

Что касается темы - то думаю всем будет плевать.

Это вызовет баги, 100%. Возможно кто-то из-за этого даже умрет :D

Документация glibc имеет приоритет над любой графоманией (т.к. она, в отличие от графомании, первоисточник)

Помимо glibc есть другие libc (в ондроеде, например). Ну и musl.

ну а авторы gcc ни в коем случае не станут ломать glibc.

Они его регулярно ломают, ты просто не сталкивался.

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

cumvillain  фанат бюрократических си-стандартов Навеяно свежей дырой в Xorg

Это не моя тема, лол.

Тема не твоя, но там был диалог.

полностью изменить логику работы программы

s/realloc/my_realloc/

Тема не твоя, но там был диалог.

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

Так логика описанная в документации glibc контринтуитивна. Я бы ожидал что realloc с нулем вернет ошибку, т.к. подобный вызов лишен практического смысла. И правильно там сделали UB

Так логика описанная в документации glibc контринтуитивна. Я бы ожидал что realloc с нулем вернет ошибку, т.к. подобный вызов лишен практического смысла.

Возможно.

И правильно там сделали UB

UB – это не ошибка. UB – возможность компилятору сделать вообще что угодно и тебе про это не сказать.

Почему лишён? Вот пример:

typedef struct {
  size_t len;
  char *data;
} dynamic_array;

int dynamic_array_set_len(dynamic_array *da, size_t len) {
  char *data;
  if(!(data=realloc(da->data,len)) && len) return -1;
  da->len = len;
  da->data = data;
  return 0;
}

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

люди, которые это пропихнули уже надели парик, приклеили бороду, усы, отрастили сиськи, поменяли паспорт и выехали в неизвесном направлении?

а то как-то рискованно все это.

Впрочем, зачем делать realloc(0) я не знаю.

0 может оказаться значением переменной.

Э, а где-то противоречие? Комитет знает про текущие реализации и UB позволяет им быть такими, но явно говорит что писать такой код не надо

Опять cumvillain опозорился – да что ж такое.

Все про мотивацию комитета в пропозале доступно изложено. Вкратце: практически все реализации и POSIX при вызове realloc(ptr, 0) ведут себя по-разному.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

Classifying a call to realloc with a size of 0 as undefined behavior would allow POSIX to define the otherwise undefined behavior however they please.

https://research.nccgroup.com/2020/04/09/c-language-standards-update-zero-size-reallocations-are-undefined-behavior/

Making this behavior undefined continues to allow existing implementations to do as they please, but provides a clear warning to developers to guard against zero-byte reallocations.

Жду мантр про «UB это когда компилятор форматирует хард».

Было до С23

if new_size is zero, the behavior is implementation defined (null pointer may be returned (in which case the old memory block may or may not be freed), or some non-null pointer may be returned that may not be used to access storage). Such usage is deprecated

Стало в C23

if new_size is zero, the behavior is undefined. 

Так что и раньше было и deprecated и implementation defined.

https://open-std.org/JTC1/SC22/WG14/www/docs/n2396.htm#dr_400

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

дом, милый дом.

Я понимаю, что нужно было принести какой нибудь пример, но можно его было сделать более валидным? Если проверять аргументы, передаваемые в функцию, после вызова функции, то можно получить кучу проблем и при этом не только в Си. Если я напишу вот так, то будет УБ?

void *resize_array(void *ptr, size_t n)
{
    if (n == 0) {
        errno = 0;
        return NULL;
    }

    ptr = realloc(ptr, n);

    if (ptr == NULL)
        errno = ENOMEM;
    return ptr;
}

Вот так и утечки создают, блин. А освобождать память перед возвратом NULL кто будет делать? Почтальон Печкин, свинка Пепе, или ещё какая мифическая сущность???

 if (n == 0) {
        free(ptr);
        errno = 0;
        return NULL;
    }

Еще спросите, зачем человек руками ставит ENOMEM потенциально перезатирая оригинальный код (даже если ман сейчас говорит что поддерживается только один)

Making this behavior undefined continues to allow existing implementations to do as they please, but provides a clear warning to developers to guard against zero-byte reallocations.

Это просто чистейший фейспалм. «Вон та реализация Keil-C кривая, поэтому давайте пусть такое поведение у всех будет». Что дальше? Объявим Microsoft-C стандартом и все будем равняться на _wstrbpbstio?

Какая вообще нахрен разница, какое поведение в конкретной реализации? Это новый стандарт, новый, блэт! Если у вас не соответствует стандарту - значит вы не соответствуете стандарту. Причем тут вообще «а вот у них нет float, давайте их уберем»

Новый код НЕ сломается пока кто-то принудительно не поставит -std=c23. Тот же самый фейспалм был с bool. Какой смысл был его выносить в отдельный заголовок? Чтобы что? Чтобы не сломать код? Какой? Который под c89/90 компилируется? Ну так у него всё будет хорошо. Зато новый код оброс костылем.

Проверить n до вызова realloc религия не позволяет?

continues to allow existing implementations to do as they please

Так и надо было тогда объявлять «implementation defined», а не UB. Клоуны.

Ничего не мешает конкретным реализациям конкретизировать это поведение. undefined это что угодно, в том числе и такое поведение.

Ничего не мешает конкретным реализациям конкретизировать это поведение.

Нет, тогда это было бы implementation defined (как было). А стало undefined behavior.

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

Разница лишь в том, что IDB имеет предопределённые варианты и требует наличия документации, в то время как к UB стандарт не предъявляет вообще никаких требований.

Впрочем, зачем делать realloc(0) я не знаю.

Мне кажется, это изначально ошибка в логике программы (=баг). Врятли кто-то так изощренно free() вызывает.

Было ID, стало UB :D

but provides a clear warning to developers to guard against zero-byte reallocations.

а где clear warning будет? В стандарте? Сишники его не читают. Короче, будет как всегда: куча воя что «ОЛОЛО СТАРЫЙ КОД РАБОТАЛ И СЛОМАЛСО СРАНЫЕ КОМИТЕТЧИКИ НАСРАЛИ МНЕ ПОД ДВЕРЬ!!!»

Сто лет в обед в варнингах.

Сто лет в обед в варнингах.

В gcc13 нет.

Я понимаю, что нужно было принести какой нибудь пример, но можно его было сделать более валидным? Если проверять аргументы, передаваемые в функцию, после вызова функции, то можно получить кучу проблем и при этом не только в Си. Если я напишу вот так, то будет УБ?

Так потеряется смысл: ptr = NULL после realloc(ptr, 0) это не ENOMEM.

Classifying a call to realloc with a size of 0 as undefined behavior would allow POSIX to define the otherwise undefined behavior however they please.

В итоге в одном стандарте будет написано что это UB, в другом не написано ничего, а в третьем glibc будет делать одно, а musl – другое. Все как мы любим :)

Вот так и утечки создают, блин. А освобождать память перед возвратом NULL кто будет делать? Почтальон Печкин, свинка Пепе, или ещё какая мифическая сущность???

Опять кто-то документацию не почитал, да?

If size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr)

В случае n == 0 realloc(ptr, n) == free(ptr).

Еще спросите, зачем человек руками ставит ENOMEM потенциально перезатирая оригинальный код (даже если ман сейчас говорит что поддерживается только один)

Потому что в документации написано, что realloc(ptr, 0) это free(ptr), который errno не трогает.

Хм, допустим. Но в clang-analyzer овер 10 лет как. И в valgrind.

Так алле, код с перетиркой errno в противоположной ветке.