Получить предупреждение о смещении влево отрицательного числа

Поведение при сдвиге влево любого значения на величину, меньшую размера слова, было определено в C89 для всех целочисленных значений левого операнда, даже несмотря на то, что указанное поведение для отрицательных левых операндов часто было бы далеко не идеальным на недвойках. дополняющие дополняющие платформы или на платформах с отловом ошибок в случаях, когда многократное умножение на два приведет к переполнению.

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

Если авторы Стандарта намеревались внести какие-либо изменения в обработку операций сдвига влево в случаях, когда поведение C89 имело смысл, в опубликованном документе «Обоснование» должно быть какое-то упоминание об этом изменении. Ничего подобного нет. Единственный вывод, который я могу сделать из такого упущения, состоит в том, что переход от «Вести себя определенным образом, который почти всегда имеет смысл» к «Вести себя таким образом, если разработчик считает, что это имеет смысл, и в противном случае обрабатывать код любым другим способом». способ, который разработчик считает нужным», не рассматривался как достаточное изменение, чтобы оправдать комментарий. Тот факт, что авторам Стандарта не удалось предписать поведение, никоим образом не означает, что они не ожидали, что реализации общего назначения с дополнением до двух не будут продолжать обрабатывать такие сдвиги, как они всегда это делали, и что программисты не должны иметь право на аналогичные ожидания.

В 5 << -4 как GCC 9.1.0, так и Apple LLVM 10.0.1 с clang-1001.0.46.4, ориентированные на x86-64, выдают предупреждающее сообщение («количество сдвигов влево отрицательное» для GCC и «счетчик сдвигов отрицательное» для LLVM- лязг). В -4 << 3 GCC не выдает предупреждения, а LLVM-clang выдает («сдвиг отрицательного значения не определен»).

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

Когда операнд не является константой, как в z << x и x << 3, мы можем предположить, что компилятор не видит, что операнд отрицателен, поэтому он не выдает предупреждение. В общем, эти выражения могут иметь определенное поведение: если x неотрицательно и находится в подходящих пределах (не больше ширины z в первом случае и не настолько велико, чтобы x << 3 переполнялось во втором случае), поведение определено (за исключением возможности переполнения z << x). Стандарт C не говорит, что сдвиги влево с типами, которые мая имеют отрицательные значения, то есть, типы со знаком, не определены, просто сдвиги влево с отрицательными значениями не определены. Поэтому для компилятора было бы ошибкой выдавать предупреждающее сообщение всякий раз, когда x был подписанным типом в таком выражении, как z << x или x << 3.

Конечно, учитывая int x = -4 и отсутствие каких-либо изменений в x между этой инициализацией и выражениями z << x и x << 3, компилятор может сделать вывод, что в данном конкретном случае сдвиги не определены, и выдать предупреждение. Этого не требует стандарт, и неспособность компилятора сделать это просто зависит от качества реализации компилятора.

Краткое объяснение того, что компилятор не выдает предупреждения в таких случаях, заключается в том, что это не требуется.

Определение «не определено» в стандарте также прямо указывает «не требуется диагностика». Это означает, что стандарт не требует реализации для выдачи диагностики в таких случаях. Причина этого в том, что технически компиляторы могут быть не в состоянии обнаружить все случаи неопределенного поведения в течение разумного времени или (в некоторых случаях) вообще. Некоторые случаи могут быть обнаружены только во время выполнения. Компиляторы представляют собой сложные фрагменты кода, поэтому, даже если человек может легко распознать проблему, компилятор может этого не сделать (с другой стороны, компиляторы также обнаруживают проблемы, которые люди не могут легко найти).

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

Первое, что происходит, сводится к проблемам «качества реализации» — поставщик или разработчик компилятора решает написать код, который обнаруживает определенные случаи, и другой код, который выдает предупреждение.

Два шага (обнаружение случая и предупреждение о нем) являются отдельными и полностью дискреционными — стандарт не требует диагностики, поэтому, даже если написан код, обнаруживающий конкретный случай, компилятор все равно не обязан выдавать предупреждение об этом. Это. На практике, даже если проблемы обнаружены, разработчики компилятора могут не выдавать предупреждение по разным причинам. Некоторые предупреждения относятся к редким пограничным случаям, поэтому не стоит их выдавать. Некоторым предупреждениям присуща частота «ложных срабатываний», что приводит к тому, что разработчики жалуются в отчетах об ошибках поставщику компилятора о ненужных предупреждениях, поэтому компилятор по умолчанию настроен так, чтобы не выдавать их.

Следующее требование для выдачи предупреждения состоит в том, что пользователь компилятора должен выбрать отображение предупреждений. Благодаря яростному лоббированию поставщиков разработчиками - большинство современных компиляторов настроены ПО УМОЛЧАНИЮ, поэтому они выдают относительно небольшое количество предупреждений. Поэтому разработчикам, которым требуется как можно больше помощи от компилятора, необходимо явно включить его. Например, используя опции -Wall с gcc и clang.