у меня были реальные кейсы, когда валгринд делал ровным счётом ничего

У меня наоборот

У меня наоборот

странно... не было ещё ни одного случая, когда libasan не нашёл бы того, что нашёл valgrind. Кстати, ты не пробовал вместе юзать их? Как оно?

мог испортиться сам строковый литерал, например)

Они же в read-only памяти по умолчанию. Упало бы раньше.

Они же в read-only памяти по умолчанию. Упало бы раньше.

Есть на это гарантии Стандарта?

странно... не было ещё ни одного случая, когда libasan не нашёл бы того, что нашёл valgrind. Кстати, ты не пробовал вместе юзать их? Как оно?

Вместе не вижу смысла, обычно компилирую с asan, если не работает, загоняю в valgrind

Есть на это гарантии Стандарта?

нет

Есть на это гарантии Стандарта?

Есть UB при попытке их изменить (const жеж). Гарантии segfault'a, естественно, нет, но на практике компилятор всегда помещает их в .rodata сегмент, который мапится как read-only.

Есть UB при попытке их изменить (const жеж). Гарантии segfault'a, естественно, нет, но на практике компилятор всегда помещает их в .rodata сегмент, который мапится как read-only.

вот и я о том же. Это UB. Мы говорим про C++, а не про реализацию

UB он и в Африке UB.

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

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

Нет, это неверно. То, что Вы говорите - это implementation-defined

Undefined - полностью неопределённое. Unspecified - стандарт даёт несколько вариантов, а какой из них - это уже на волю компила

вроде так, если не напутал

Ну и это вдогонку: http://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior

Нет, это неверно. То, что Вы говорите - это implementation-defined

Ну любое неопределенное поведение в итоге как-то определено

Ну любое неопределенное поведение в итоге как-то определено

смысл в том, описывается ли это в спецификации компилятора

Ну любое неопределенное поведение в итоге как-то определено

и ни у кого нет гарантий, что там при UB не стоит rand() % 42

Разработчики компиляторов адекватные люди.

и ни у кого нет гарантий, что там при UB не стоит rand() % 42

Ну гарантий нет, но если стоит rand%42 уже 8 версий и никто код не трогает, то это вполне определенно)

Разработчики компиляторов адекватные люди.

Никто этого не отрицает. Но факт остаётся фактом - UB есть UB

Ну гарантий нет, но если стоит rand%42 уже 8 версий и никто код не трогает, то это вполне определенно)

А если он энтропию от проца берёт??

если

Я говорю о том, что такой код: ''' int* x = nullptr; *x = 123; ''' скомпилированный череез g++\clang на x86(-64) под линуксом гарантированно дает segfault хоть это и UB. Ядерные ракеты такой код (внезапно!) не запустит.

не те 'кавычки' -_-

Я говорю о том, что такой код: ''' int* x = nullptr; *x = 123; ''' скомпилированный череез g++\clang на x86(-64) под линуксом гарантированно дает segfault хоть это и UB. Ядерные ракеты такой код (внезапно!) не запустит.

Внезапно этот код работает если вы пишите под BIOS

Я говорю о том, что такой код: ''' int* x = nullptr; *x = 123; ''' скомпилированный череез g++\clang на x86(-64) под линуксом гарантированно дает segfault хоть это и UB. Ядерные ракеты такой код (внезапно!) не запустит.

1) Вы наложили неплохое такое ограничение на: компиляторы, платформу, ОС. 2) Нет гарантий, что не запустит (по крайней мере гарантий со стороны Стандарта)

А если он энтропию от проца берёт??

Ещё хуже... Современные компиляторы оптимизируют основвываясь на UB. Если код с UB работает на gcc-6.2, то на gcc-6.3 могут добавить оптимизацию и код работать перестанет.

Ещё хуже... Современные компиляторы оптимизируют основвываясь на UB. Если код с UB работает на gcc-6.2, то на gcc-6.3 могут добавить оптимизацию и код работать перестанет.

Знаю-знаю. Мне кажется, что лучшим пособием по тому, что такое UB, и чем оно опасно, является доклад Маршалла

Да, я из него черпал инфу :)

https://www.youtube.com/watch?v=4GUuek7_OhU

Ещё хуже... Современные компиляторы оптимизируют основвываясь на UB. Если код с UB работает на gcc-6.2, то на gcc-6.3 могут добавить оптимизацию и код работать перестанет.

Наоборот же, часть UB ситуаций были введены чтобы компиляторам было проще оптимизировать.

Наоборот же, часть UB ситуаций были введены чтобы компиляторам было проще оптимизировать.

Вы оба сказали ордно и то же, просто разными словами ?

1) Вы наложили неплохое такое ограничение на: компиляторы, платформу, ОС. 2) Нет гарантий, что не запустит (по крайней мере гарантий со стороны Стандарта)

Речь с самого начала шла о таких ограниченниях

Речь с самого начала шла о таких ограниченниях

не вижу, где мы накладываем такое ограничение. Можешь подсказать? ?

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

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

а, ты про это. Согласен, это ограничение. Но это не отменяет того факта, что UB - это игра в лотерею. О чём, кстати, и говорит фраза "в большинстве случаев"

Внезапно этот код работает если вы пишите под BIOS

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

Хз, мб ща найду

#include <iostream> int main (){ std::cout << "Hello World!"; return 0; }

/tmp/ccea35T1.o: In function `main': learn.cpp:(.text+0xa): undefined reference to `std::cout' learn.cpp:(.text+0xf): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' /tmp/ccea35T1.o: In function `__static_initialization_and_destruction_0(int, int)': learn.cpp:(.text+0x3d): undefined reference to `std::ios_base::Init::Init()' learn.cpp:(.text+0x4c): undefined reference to `std::ios_base::Init::~Init()' collect2: error: ld returned 1 exit status

Вот почему, нльзя сесть спокойно ипо урокам делать??

Мне дали ссылку на уроки learncpp.com

Вот написал как там написано и вот что.

Подскажите плиз чо за фигня.

это уже С++, там компилятор С?

Ну я делаю gcc file.cpp

Ну я делаю gcc file.cpp

1. g++ 2. #supapro

Извиняюсь за тупость.

ERROR: S client not available

Парни, есть какие-нибудь каналы в телеграме по C++?

Уже вот тут

Добро пожаловать

> каналы

?

А, в глаза долблюсь, бывает )

Парни, есть какие-нибудь каналы в телеграме по C++?

@procxxnews

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

А по Qt есть какие-нибудь живые чаты и каналы? Язык не важен, лишь бы поговорить можно было.

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

да можно и сюда я думаю

тут кутешников много, я один из них

алсо вот, ребят. вспомнил. поставил сегодня на пробу resharper - плагин для V2013. прогнал его на одном проекте. и он выдал такое странное предупреждение. суть в следующем

class C { public: C() { val |= some_bitmask; // warning - value may be unitialized } int val = 0; }

ну примерно так

мне казалось - если с C++11-style что-то инициализируется, то в теле конструктора оно уже присвоено, разве нет?

т.е. порядок инициализации - вроде он такой

список инициализации, затем инициализация в объявлении класса, затем уже тело конструктора

я видимо не прав?

в дебаггере погонял - так и есть

а значение битмаски какое?

какое-то. неважно. 2,4,8, ... - какие-то биты

может он про some_bitmask?

это просто так