- 1
http://www.ssw.uni-linz.ac.at/Research/Papers/Wuerthinger07/Wuerthinger07.pdf
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+3
http://www.ssw.uni-linz.ac.at/Research/Papers/Wuerthinger07/Wuerthinger07.pdf
Как известно, в языках C и C++ есть проблема с buffer overflow, в то время как в языке Java такой проблемы нет (баги в реализации самой JVM не рассматриваем). В языке Java, как и в многих других подобных языках для анскиллябр заедушных, не могущих в сырые указатели, сделали проверки границ массива. В говноязыке C++ впрочем тоже есть какая-то такая питушня, например std::vector::at выполняет роверку выхода индекса за границы диапазона вектора. Только вот в язык JVM давно уже внедряют такую хреноту, как array bounds check elimination, т.е. убирание проверок, когда на этапе компиляции можно доказать, что такие проверки не нужны.
В какой версии C++ сделают чтоб std::vector::at тоже вот так могло автозаменяться на небезопасный аналог если компилятор доказал что там эти проверки не нужны?
Antervis 03.05.2018 06:58 # +2
думаю, это примерно начиная с версии "говно бронтозавра" https://godbolt.org/g/Kq4mJJ
j123123 03.05.2018 07:51 # +1
j123123 03.05.2018 07:55 # +2
.L20, .L21, .L22 - метки, куда прыгаем если возникает эксепшен, и для каждого std::vector::at по проверке, хотя тут бы хватило одной проверки интервала
bormand 03.05.2018 08:16 # +2
Ну здесь нельзя винить конпелятор — исключения то разные. Откуда ему знать, что "a[1] не найден" и "a[2] не найден" для тебя однохуйственны?
j123123 03.05.2018 17:03 # −2
Sim_salapim 03.05.2018 17:36 # 0
Alexander 03.05.2018 17:46 # 0
Antervis 03.05.2018 09:53 # +2
bormand 03.05.2018 07:44 # +2
Дык давно выбрасывают. И даже простую арифметику над диапазонами умеют в этом доказательстве проделывать.
Вот только работает эта хрень обычно только на знаковых интах (т.к. их переполнение не определено). А на беззнаковых конпелятор часто ссыт испортить логику и оставляет всё как есть.
bormand 03.05.2018 07:52 # +1
sizeof(T)*i < buf_size
Вдруг программист тут и правда хотел получить и обработать переполнение?
Alexander 03.05.2018 08:40 # +2
Метод от противного?
j123123 03.05.2018 08:12 # +1
А этот механизм реализован непосредственно в компиляторе, или это решается каким-то шаблонным и/или constexpr говном?
http://www.ciselant.de/projects/gcc_printf/gcc_printf.html например оптимизации, связанные с использованием printf (всякие там замены printf на puts и putchar для частных случаев) реализованы в самом компиляторе, а не какой-то шаблоноеблей (которой в сишке просто нет)
bormand 03.05.2018 08:50 # +2
Где-то мы же уже обсуждали наивную функцию вывода числа, где gcc выбросил все проверки (включая проверку на (digit < '0' || digit > '9') и вывел %&^#@^!* для числа Тараса.
yet_another_one_shit 03.05.2018 13:54 # 0
ЗЫ. Где это?
yet_another_one_shit 03.05.2018 14:05 # +1
http://govnokod.ru/19385
j123123 03.05.2018 17:00 # 0
bormand 03.05.2018 17:52 # +1
bormand 03.05.2018 18:00 # +2
dm_fomenok 04.05.2018 11:51 # +1
roskomgovno 04.05.2018 19:24 # 0
yet_another_one_shit 03.05.2018 13:53 # 0
ХУЙНЯЯ
roskomgovno 04.05.2018 04:27 # 0
subaru 04.05.2018 10:12 # 0
roskomgovno 04.05.2018 19:24 # 0