> аналитику не надо уметь пользоваться Visual Basic'ом в Excel'е
Особенно весело (так весело, что аж страшно) будет примерно через пол-года, когда макросы разростутся на пару тысяч строк и этой книгой (к тому же лежащей в расшареном каталоге) будет пользоваться весь отдел аналитики.
9, 10, 11. То есть, вы считаете, что если сложение чисел со знаком реализовано через add на x86, то вы можете рассчитывать на свойства переполнения чисел со знаком (конечно, расставив нужные макросы условной компиляции «только x86»)?
И да, не согласен с выводом. Поясню: а по сравнению с malbolge С++ вообще кристально ясен. Моё мнение: в Си слишком много UB и встроенных правил (те же usual arithmetic conversions).
7. В любом коде на Си есть приведения типов указателей. Кто даст гарантию, что они корректны? И далеко не всем очевидно, что так делать нельзя. И не обязательно передавать указатели вот так явно в функцию, их можно доставать из структур ланных или ещё как-то. К тому же, не все компиляторы используют sctrict aliasing при оптимизации и поэтому многие прораммисты даже не догадываются об этом (пока им не приходится портировать свой код на более строгий компилятор).
8. В макросах достаточно часто используются запятые. Замените константы на вызовы функций и варнинги исчезнут.
Это ортогональная вещь, неявные преобразования типов (которые не мешают языку быть статически типизированным, правда обычно в статически типизированных языках таких свободных преобразований нет).
Это пример. Упрощённый пример. Эти указатели не обязательно передавать в функцию, их можно получать через вызов другой функции, или найти в какой-то структуре данных или ещё как-нибудь.
Давайте конкретные паттерны и будут варнинги в компиляторе. Только знаете в чём проблема? Этого не будет, потому что все приведённые в статье конструкции используются во вполне корректном коде.
g++ варнинг не выдаёт. clang выдаёт. Это, конечно, ещё раз показывает преимущество clang в диагностиках, но программистам, использующим gcc от этого не легче.
2. Представьте себе, что это критически важная функция, например в ядре, пусть если bar() выполняется, то это уязвимость. Вы исправляете баг, который случайно нашли «глазами». Если вы не выпустите security bulletin, то вы «тихо» закрыли уязвимость и поэтому кто-то мог не пропатчить свою систему.
7. Вы никогда не приводите указатели в Си? Всегда дотошно проверяете, что не нарушаете алиасинг?
8. Запятая широко используется в макросах. Код в примере вполне может быть результатом препроцессирования нескольких макросов.
Это предсказуемая вещь пока компилятор не станет умнее и кто-то (из лучших убеждений, стараясь помочь программистам отлавливать UB) не будет вставлять abort() вместо разыменовывания null pointer если это видно статически. И компилятор, что, самое интересное, будет прав, и подавляющее большинство программистов будут только рады такому новому поведению.
> Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer
Я согласен что по физическому адресу, соответствующему null pointer может что-то лежать и тем, что лежит ниже реализации Си (процессор/ВМ) разрешается читать/писать эту ячейку памяти, но в стандарте это UB. Понимаете, UB может означать «аварийное завершение», а может «какое-то действие». Поэтому на практике у вас даже может получаться записывать *(int *)0 = 42; и считывать обратно, но это всё равно UB.
Компиляторы — не обязаны, в рантайме падение тоже не гарантируется (undefined behavior — это всё что угодно, в том числе и игнорирование проблемы: как, например, переполнение чисел со знаком игнорируется в большинстве компиляторов Си для x86).
Особенно весело (так весело, что аж страшно) будет примерно через пол-года, когда макросы разростутся на пару тысяч строк и этой книгой (к тому же лежащей в расшареном каталоге) будет пользоваться весь отдел аналитики.
8. В макросах достаточно часто используются запятые. Замените константы на вызовы функций и варнинги исчезнут.
7. Вы никогда не приводите указатели в Си? Всегда дотошно проверяете, что не нарушаете алиасинг?
8. Запятая широко используется в макросах. Код в примере вполне может быть результатом препроцессирования нескольких макросов.
6.5.3.2 p4
> Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer
Я согласен что по физическому адресу, соответствующему null pointer может что-то лежать и тем, что лежит ниже реализации Си (процессор/ВМ) разрешается читать/писать эту ячейку памяти, но в стандарте это UB. Понимаете, UB может означать «аварийное завершение», а может «какое-то действие». Поэтому на практике у вас даже может получаться записывать *(int *)0 = 42; и считывать обратно, но это всё равно UB.