Большинство подобных UB выявляются компиляторами (clang лучше чем gcc) и статическими анализаторами (чем дороже тем эффективнее от cpplint до prevent)
2 и 7 могут проявится только при высоком уровне оптимизации (больше -O2 в gcc), когда компилятор начинает делать небезопасные оптимизации. А, вообще, компиляторы всегда стараются придерживатся консервативной стратегии по умолчанию.
Ответил неправильно на 5 из 12 в основном на вопросы касающиеся переполнения.
на 4й вопрос есть еще один ответ. если в коде выше будет определен #define NDEBUG, то ассерты будут выключены и функция может получить 0.
Автору так же, наверное, стоило бы добавить что таких «темных мест» в c++ гораздо больше ;)
Пример интересен как пруф-оф-консепт или в блог ненормальное программирование :-)
Применение каррирование и прочих функциональных штук в строго-типизированном языке — это извращение, на мой взгляд.
Не буду повторять вопросов о целесообразности данного подхода, высказанных выше.
У меня небольшая заметка по реализации. Так как вы сказали что не доверяете руту, то использование некриптографического генератора случайных чисел (rand()) является серьезной уязвимостью, так как с легкостью может быть предсказанно, даже после использования seed(time()).
>А со статическими анализаторами у Вас опыт работы есть?
Из статических анализаторов у меня есть опыт работы с flexelint и проприетарными статическим анализатором.
>Платформа только Unix интересует?
Да, меня интересует только Unix интересует, если быть точнее то Android платформа.
Я бы хотел уточнить, что данное направление меня интересует скорее с R&D точки зрения.
Нет, я не занимаю разработкой динамических анализаторов.
Я всего лишь пытаюсь применить данные инструменты для решения задачи эффективного повышения качества кода и снижения трудозатрат тестирования.
Говоря о динамическом анализе, я имел ввиду относительно новый подход к анализу программ, представленный в этой статье.
JUnit и другие фреймворки модульного тестирования – это тесты написанные вручную. Статья о современных попытках переложить часть этой важной, но рутинной процедуры на автоматические средства. Ко всему, давайте не будем забывать о разнице в покрытии строк кода и всех путей в программе. Вручную практически нереально написать такое астрономическое количество тестов которые бы покрывали всевозможные пути в программе. А только такой набор тестов может гарантировать отсутствие ошибок.
Но, да согласен, что без практических примеров не сразу понятно о чем идет речь. Примеры использования программ я решил перенести в следующую часть, иначе статья оказалась бы слишком большой.
perfperf -f -g -p pid
2 и 7 могут проявится только при высоком уровне оптимизации (больше -O2 в gcc), когда компилятор начинает делать небезопасные оптимизации. А, вообще, компиляторы всегда стараются придерживатся консервативной стратегии по умолчанию.
Ответил неправильно на 5 из 12 в основном на вопросы касающиеся переполнения.
на 4й вопрос есть еще один ответ. если в коде выше будет определен #define NDEBUG, то ассерты будут выключены и функция может получить 0.
Автору так же, наверное, стоило бы добавить что таких «темных мест» в c++ гораздо больше ;)
Применение каррирование и прочих функциональных штук в строго-типизированном языке — это извращение, на мой взгляд.
У меня небольшая заметка по реализации. Так как вы сказали что не доверяете руту, то использование некриптографического генератора случайных чисел (rand()) является серьезной уязвимостью, так как с легкостью может быть предсказанно, даже после использования seed(time()).
Из статических анализаторов у меня есть опыт работы с flexelint и проприетарными статическим анализатором.
>Платформа только Unix интересует?
Да, меня интересует только Unix интересует, если быть точнее то Android платформа.
Я бы хотел уточнить, что данное направление меня интересует скорее с R&D точки зрения.
Я всего лишь пытаюсь применить данные инструменты для решения задачи эффективного повышения качества кода и снижения трудозатрат тестирования.
Говоря о динамическом анализе, я имел ввиду относительно новый подход к анализу программ, представленный в этой статье.
Но, да согласен, что без практических примеров не сразу понятно о чем идет речь. Примеры использования программ я решил перенести в следующую часть, иначе статья оказалась бы слишком большой.