Навеяно свежей дырой в Xorg

Насчёт реже - сомневаюсь, но то, что легче найти, бесспорно. Надо бы в си++ сделать аналог (safe и внутри него unsafe, так как должна быть совместимость).

На reddit увидел картинку :)

https://i.redd.it/bagda5b0eyga1.png

https://godbolt.org/z/xWfc1W6zb

вся тема: https://www.reddit.com/r/ProgrammerHumor/comments/10wur63/isnt_c_fun/

Да ладно! Clang это пропустил? Если не ошибаюсь - это warning в C (по крайней мере 89х) и error в C++… Но «красиво» ;)

О, я тебе сейчас вообще мозг порву

    int* a = malloc(sizeof(int)*3);
    a[0] = 666;
    a += 5;
    a -= 5;
    printf("%d\n", *a);

А как его сломать? У меня clang выкидывает аллокацию и напрямую суёт 666 в printf.

чо сказать то хотел, мамкин взрыватель мозга?

чо сказать то хотел, мамкин взрыватель мозга?

Что стандарт читать надо.

А как его сломать? У меня clang выкидывает аллокацию и напрямую суёт 666 в printf.

А никак. Работает на 99,999999999% архитектур и компиляторах, однако не отменяет того факта, что это UB.

Работает на 99,999999999% архитектур и компиляторах, однако не отменяет того факта, что это UB.

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

Если в программе есть UB, значит твоя программа некорректна

Так-то оно так, но в этом конкретном случае я не до конца понимаю какую практическую пользу из конкретно этого UB можно извлечь в принципе.

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

Как компилятор вообще хоть что-то может предполагать о free(), учитывая что я могу подсунуть свою в runtime?

Но ты же умнее разработчиков компилятора, правда?

Разработчики компилятора в определённом смысле заложники разработчиков апликух, и без оных не стоят вообще ничего. Компилятор который генерит код взрывающийся на ровном месте будет мгновенно выкинут на помойку. Так же как и (например) машина с ресурсом педали тормоза в 10 нажатий, и никакие отмазки вида «ну у нас же там в инструкции мелким шрифтом написано» не помогут.

Так-то оно так, но в этом конкретном случае я не до конца понимаю какую практическую пользу из конкретно этого UB можно извлечь в принципе.

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

Как компилятор вообще хоть что-то может предполагать о free(), учитывая что я могу подсунуть свою в runtime?

Легко. В стандарте языка написано, что он может, значит он может.

Это C, его разумом не понять. Он нужен в основном во имя страданий.

Вы не котиков не любите, Вы их готовить не умеете.

Легко. В стандарте языка написано, что он может, значит он может.

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

Пример из жизни: QObject::connect. Принимает сырые указатели, сохраняет. Достаточно крови попортило.

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

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

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

он же отлеживает время жизни объектов?

В целом да, но есть нюансы. Мы ловили тонкие рейсы не раз. Емнип, обработчик вызывался в процессе разрушения объекта-ресивера, но до деструктора родительского QObject, так что Qt еще не считал его мертвым.

Или речь о вариантах с лямбдами?

На это тоже напарывались, но быстро научились указывать контекст.

Так-то оно так, но в этом конкретном случае я не до конца понимаю какую практическую пользу из конкретно этого UB можно извлечь в принципе.

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

p = malloc(...):
...
free(p);
q = malloc(...);
if(p == q) {
  magick_run();
}

Компилятор имеет право убрать проверку на p == q, а не выполнять magick_run в зависимости от того, попал ли новый объект на место старого.

А тут другое UB. Ты не можешь сравнивать два указателя, за исключением особых случаев. То есть даже без вызова free() тут всё плохо.

Компилятор имеет право убрать проверку на p == q, а не выполнять magick_run в зависимости от того, попал ли новый объект на место старого.

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

а каков смысл этого?

В C нет смысла. Только БОЛ и СТРАДАТ.

А тут другое UB. Ты не можешь сравнивать два указателя, за исключением особых случаев. То есть даже без вызова free() тут всё плохо.

Ты не путаешь с relational comparison?

Смотри тут:

Навеяно свежей дырой в Xorg (комментарий)

Т.е. путаешь

Нет, не путаю. Там нет различий между больше-меньше и равно в этом плане.

Тем не менее, ==/!= описано отдельно http://port70.net/~nsz/c/c11/n1570.html#6.5.9p6

Ага, но в этом пункте нет про UB. А в предыдущем есть. И про equal там тоже есть.

Это, на самом деле, отдельная проблема, что стандарт написан членом.

Ага, но в этом пункте нет про UB.

Вот и отлично!

А в предыдущем есть.

Так он не релевантен.

Это, на самом деле, отдельная проблема, что стандарт написан членом.

Какая радость для тех, кто читает жёппой))0)0

Но вообще тут всё ок с написанием. Вот почему некоторые, когда хотят узнать про поведение выражения p == q, лезут в раздел про операторы </<=/>/>= — это вопрос.

https://eel.is/c++draft/expr.eq#3.1

(3.1)

If one pointer represents the address of a complete object, and another pointer represents the address one past the last element of a different complete object, the result of the comparison is unspecified.

(3.2)

Otherwise, if the pointers are both null, both point to the same function, or both represent the same address, they compare equal.

(3.3)

Otherwise, the pointers compare unequal.

И к чему это?

а каков смысл этого?

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

Например

if(f(x)) { do_p(p); free(p); }

do_something_else();

if(some_else(y)) { g(p); }

Так как компилятор видит, что g(p) не может быть вычислено после free(p), то если some_else не имеет побочных эффектов, то компилятор может запомнить значение f(x) и если оно истинно, то не вычислять some_else.

Или может сразу после free(p) использовать регистр, в котором хранилось значение p, для каких-то других целей (тогда если программист допустил ошибку и f(x) и some_else(y) одновременно истинны, то в g будет передано некой произвольное значение).

и написал такой вот проверочный код

Этот код некорректен. Можешь перед освобождением преобразовать в число или строку и сравнивать эти числа или строки.

Так как компилятор видит, что g(p) не может быть вычислено после free(p), то если some_else не имеет побочных эффектов, то компилятор может запомнить значение f(x) и если оно истинно, то не вычислять some_else.

откуда у «компилятора» такие мыслищи???

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

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

if(f(x)) { do_p(p); free(p); }
do_something_else();
if(some_else(y)) { g(p); }

Компилятор имеет право убрать проверку на p == q, а не выполнять magick_run в зависимости от того, попал ли новый объект на место старого.

a malloc может вернуть еще и NULL. причем оба раза. и получается уже не сравнение двух адресов, а NULL==NULL что есть тождественное равенство, и надо ветку выполнять.

Не. В стандарте под сравнением с NULL имеется ввиду сравнение именно с константой NULL.

Не. В стандарте под сравнением с NULL имеется ввиду сравнение именно с константой NULL.

не об это речь. а речь о том, что

auto p = malloc(100);
auto pp = malloc(100);
if (p == pp) do_something();
else do_else();

тут нельзя полагать что p и pp разные. они могут быть и одинаковыми и равными null. то есть нельзя выкидывать do_something и оставлять только do_else при оптимизации

тут нельзя полагать что p и pp разные. они могут быть и одинаковыми и равными null. то есть нельзя выкидывать do_something и оставлять только do_else при оптимизации

Почему?

что почему? если хипменеджер нормально алокировал оба куска - то адреса разные, если не может аллокировать - там два нула. то есть при оптимизации нельзя считать что равенство p==pp никогда не выполняется и выбрасывать true ветку

Хотя ты прав, да. Я из-за этого треда уже столько в стандарт втыкал, у меня в голове всё спуталось.

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

если вставить вот это в compiler explorer

extern void func1( void* fp); ///типа внешняя функция, чтобы не заоптимизировалось в нуль.

void test__test() {
   auto lp = malloc(1000);
   auto lpp = malloc(1000);
   func1(lp);
   if (lp == lpp) func1(lpp);
}

то clang при -02 выкидывает второй вызов func1, считая что указатели не могут быть одинаковыми. но поскольку по стандарту malloc может вернуть и NULL, то такое утверждение слишком сильно.

test__test():                        # @test__test()
        push    rax
        mov     edi, 1000
        call    malloc@PLT
        mov     rdi, rax
        pop     rax
        jmp     func1(void*)@PLT                  

Пожжи.. а куда он второе выделение памяти дел?

тоже выкинул, поскольку после выкидывания ветки, указатель уже не используется.

Меня тут другое смущает: код из func1 не возращается, потому что там jmp вместо call. С другой стороны, тут UB, поэтому упс и ах.

потому что хвостовой вызов там. если будет не хвостовой - будет call.

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

Да, и правда. Не знал про эту оптимизацию.

что g(p) не может быть вычислено после free(p)

Не удержался. Что именно означает «не может быть вычислено» в этом контексте?

но поскольку по стандарту malloc может вернуть и NULL, то такое утверждение слишком сильно.

https://discourse.llvm.org/t/why-we-assume-malloc-always-returns-a-non-null-pointer-in-instruction-combing/36076/10

В общем, если нет разыменования, то компилятор трактует вызов malloc как вызов такой версии malloc, которая никогда не возвращает NULL (допустимо по стандарту).

Вплоть до того, что

int main() {
   int* lpp = (int *)malloc(-1);
   if (lpp == NULL) printf("nil\n");
}

никогда не вызывает printf.

Значение указателя не может быть использовано. Передача в функцию является использованием.

g(…) может просто проверять подставленный параметр на нулл

Это после free тоже запрещено.

Значение указателя не может быть использовано. Передача в функцию является использованием.

Мне трудно описАть насколько это для меня бессмысленно. При первой возможности пообщаюсь со «власть имеющими» - бред же конкретный… Хочется верить что имеем дело с неправильной интерпретацией стандарта. Или наличием адекватных людей среди разработкиков компиляторов «кладущих» на инструкции «сверху».

Это после free тоже запрещено.

Hold on. Кто-то ссылался на 7.20.3(.2). И где здесь что-то написано про «низзя»? Я на неправильную pdf’ку смотрю?

The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined.

Всё что написано выше (а) правда (б) имеет смысл и (в) из этого ну никак не следует тезис об

По сути же получается, что практически любое сравнение указателей (или даже печать значения указателя) – это потенциальный UB

Не по сути, а по стандарту лул :DDDD

ПыСы. Это я пытался в треде ссылку на конкретный параграф найти где говорится что-то большее про использование указателя чем разыменование after free() (дабы нашим «знатокам» предьявить)…

На правильную. В ней на странице 502:

J.2 Undefined behavior
...
- The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3).

То есть нельзя использовать значение указателя, ссылающегося на место, попавшее в free или realloc.