Скучная сишка

Чем вспоминать каждый раз,

Просто аккуратней пиши. Если использовать здравый смысл, то вероятность столкнуться с UB в Си не больше вероятности встретить на улице лиспера.

i++ + ++i

вероятность столкнуться с UB в Си не больше вероятности встретить на улице лиспера

Если честно, ни разу не видел программы на C или C++ больше сотни строк, которая бы так или иначе не содержала UB. Зачастую это осознанный выбор разработчика.

что такое UB ?

Undefined behaviour

Overall I think that these people simply don't understand what most C programmers want

Мне кажется именно этот чувак не очень понимает, что нужно людям, пишушим на Це. Для того, чтобы раз и навсегда зафиксировать все эти «undefined» or «unspecified» or «implementation-defined», придётся пускать программы в виртуальной машине. Он правда думает, что сишники на самом деле в глубине души хотят писать на жабе?

Сколько уже можно? Дайте уже сишке завоевать мир!

Производительность для большинства задач проблема даже не первого десятка

Вот только всякая крипта, о которой идёт речь, в список этих задач не входит

Звучит разумно, хорошо и полезно, только возможно будет сложно придумать все это под разные архитектуры и ОСи.

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

Спасибки

Так это повлияет на возможности оптимизации. А все ради тех, кому лень придерживаться стандарта.

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

А можно примеры таких программ? Хочу держаться от них как можно дальше.

Зачастую это осознанный выбор разработчика.

UB - это осознанный выбор разработчика? Что-то новенькое.

А можно примеры таких программ? Хочу держаться от них как можно дальше.

Ядро линукса подойдёт?

UB - это осознанный выбор разработчика?

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

Зря из толксов убрали.

выберет к-л конкретное

к-л?

Так это повлияет на возможности оптимизации.

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

Тут есть проблема - очень многое из UB проверить можно только в рантайме.

Ядро линукса подойдёт?

А где там UB?

UB - это осознанный выбор разработчика?

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

Может вы путаете UB с compiler specific behaviour?

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

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

Оптимизируют не UB, а нормальный код.

Как это говно отлаживать потом?

Зачем писать говно?

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

к-л

Какое-либо

А где там UB?

Например, в макро

#define container_of(ptr, type, member) ({                      \
        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
        (type *)( (char *)__mptr - offsetof(type,member) );})

Может вы путаете UB с compiler specific behaviour?

Не путаю. И да, в стандарте нет понятия «compiler specific behaviour».

Зачем писать говно?

Мужик, ты гений! Мы просто должны перестать совершать ошибки при написании программ, это же так просто! И почему до сих пор об этом никто не подумал?

Да, и коллег попросите!

Это не UB. Это даже не C-код, это gcc-код.

Я имел в виду не typeof, который является расширением gcc, а часть про разыменование нулевого указателя.

natural language UB :)

Это не разыменование афаик, как и в аналогичном случае с sizeof().

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

Стандарта, который регламентирует нестандартное поведение?

Только знает об этом только gcc, поэтому в gcc это работает. А с точки зрения стандарта Це это UB.

Это не UB даже в случае sizeof().

Производительность для большинства задач проблема даже не первого десятка

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

А арифметику указателей выкинуть вообще? Потому что иначе ведь от UB избавиться нельзя. И приведение типов указателей тоже. И что делать с указателями на локальные переменные?

Потом, что делать с управлением памятью? GC сделать? Потому что иначе, опять же, от UB не избавиться.

лучше следовать принципу debug once, compile everywhere

Да щас. Пока у тебя библиотеки и ядра разные, не избавишься ты от этого.

Это не UB в случае sizeof, про который стандарт что-то знает. С точки зрения стандарта C, «typeof» — это какой-то идентификатор без особых свойств.

С точки зрения C это просто невалидный код. И всё. UB возникает когда код исполняется, но что делает неизвестно. Для C UB не может возникнуть в ситуации когда код не компилится.

In computer programming, undefined behavior (UB) is the result of executing computer code written in a programming language for which the language specification does not prescribe how that code should be handled.

Как можно получить UB от того, что тупо не работает?

На всякий случай отмечу, что по документации самого gcc такое выражение не является UB:

https://gcc.gnu.org/onlinedocs/gcc/Typeof.html

The operand of typeof is evaluated for its side effects if and only if it is an expression of variably modified type or the name of such a type.

Работает по тому же принципу, что и sizeof()

Это не UB в случае sizeof, про который стандарт что-то знает. С точки зрения стандарта C, «typeof» — это какой-то идентификатор без особых свойств.

Который употреблён вместо имени типа (после const). Это будет синтаксическая ошибка. А начиная с C99 implicit function declaration вообще нету, необъявленный идентификатор — это всегда ошибка.

Lol, почему бы просто не использовать -Wundefined-behaviour -Werror ? В отличии от сабжа, код после этого будет работать везде (на всех компиляторах). Да, а сабж таки привёл бы к говнокоду, который работает только на одном компиляторе, а на остальных - как получится.

#include <stdio.h>

int main()
{
  char a = 1;
  while (a++ > 0);
  puts("hello ub!");
  return 0;
}

какую опцию предлагаешь использовать в этом случае?

писать секурно на с это утопия. надо либо на окамле или аде какой-нибудь.

i++ + ++i

Если так сильно дрожат руки — может, стоит завязывать с пьянками?

По стандарту это UB.

Да.

Работает только потому, что в gcc так можно делать.

Так можно делать во многих компиляторах, поскольку это сделано для «совместимости» со старым кодом.

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

И да, в стандарте нет понятия «compiler specific behaviour».

Тем не менее, это именно compiler specific behaviour.

Мужик, ты гений!

Спасибо.

Мы просто должны перестать совершать ошибки при написании программ, это же так просто! И почему до сих пор об этом никто не подумал?

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

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

Стандарта, который регламентирует нестандартное поведение?

Я не понял, что вы хотели сказать.

Потом, что делать с управлением памятью? GC сделать? Потому что иначе, опять же, от UB не избавиться.

Это ещё почему?

Неправильная арифметика указателей может привести к UB. Двойной free() или освобождение памяти не выделенной с помощью malloc() это тоже UB. Проблематично убрать UB оставив при этом операции с указательными и ручным высвобождением памяти.

Во-первых, этот пример не жизненный, так что не понятно, в чём именно твоя проблема. Во-вторых, можно запретить использовать мат. операции на char без уточнения signed/unsigned. В-третьих, как спасёт от этого т.н. boring c? Что, если на платформе char имеет 12 бит?

Это ещё почему?

В дополнение к тому, что сказал omnomnomnus, подумай вот о какой ситуации:

1. Программа выделила место в куче и поместила туда некоторую структуру.
   
2. Указатель на эту структуру был сохранён в нескольких местах.
   
3. Этот участок памяти был освобождён.
   
4. В какой-то момент этот участок памяти был снова выделен под другой объект.
   
5. По ошибке программиста где-то произошло обращение к первоначальной структуре обратился после её освобождения.

Как тут избавиться от UB? На шаге 5 при обращении получится мусор вместо данных.

Если использовать здравый смысл, то вероятность столкнуться с UB в Си ...

... близка к 100%