Это маскировка перед беззнаковый сдвиг влево на C/С++ тоже параноик?

говоря о с-стороне проблемы,

1. правильно ли я рассуждаю, и является ли это законной проблемой в теории?

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

1. можно ли эту проблему игнорировать, потому что на каждой платформе следующий целочисленный тип удваивает ширину?

C не требует такого отношения между целочисленными типами,хотя на практике это повсеместно. Если вы не однако, решив полагаться только на стандарт, то есть, если вы прилагаете усилия для написания строго соответствующего кода, Вы не можете полагаться на такие отношения.

1. является ли хорошей идеей правильно защититься от этой патологической ситуации, предварительно замаскировав вход таким образом?: b = (a & 1)

тип unsigned long гарантированно имеет не менее 32 бит значения, и он не подлежит продвижению к любому другому типу в рамках целочисленных акций. На многих популярных платформ, он имеет точно такое же представление, как uint32_t, и может быть даже того же типа. Таким образом, я был бы склонен написать выражение следующим образом:

uint32_t a = (...);
uint32_t b = (unsigned long) a << 31;

или, если вам нужно a только в качестве промежуточного значения при вычислении b, затем объявите его как unsigned long to начинаться.

Q1: Маскировка до сдвиг предотвращает неопределенное поведение, которое имеет отношение к OP.

Q2:"... потому что на каждой платформе следующий целочисленный тип удваивает ширину?" --> нет. "Следующий" целочисленный тип может быть меньше 2x или даже того же размера.

следующее хорошо определено для всех совместимых компиляторов C, которые имеют uint32_t.

uint32_t a; 
uint32_t b = (a & 1) << 31;

Вопрос 3: uint32_t a; uint32_t b = (a & 1) << 31; не ожидается, что код, который выполняет маску-он не нужен в исполняемый файл-только в исходнике. Если маска действительно возникает, получить лучший компилятор должен быть проблемой.

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

uint32_t b = (a & 1U) << 31;

---

@John Bollinger хороший ответ хорошо описывает, как справиться с конкретной проблемой OP.

The общие проблема заключается в том, как сформировать число, которое имеет по крайней мере n бит, определенный знак-ness и не подвержены удивительным целочисленным акциям-ядро дилеммы OP. Ниже выполняется это путем вызова unsigned операция, которая не изменяет значение - эффективный нет-op, кроме проблем типа. Продукт будет по крайней мере ширина unsigned или uint32_t. Литье, в общем, может сузить тип. Литье необходимо избегать, если сужение не обязательно произойдет. Компилятор оптимизации не будет создавать ненужные код.

uint32_t a;
uint32_t b = (a + 0u) << 31;
uint32_t b = (a*1u) << 31;

чтобы избежать нежелательного продвижения, вы можете использовать больше тип с помощью typedef, как

using my_uint_at_least32 = std::conditional_t<(sizeof(std::uint32_t) < sizeof(unsigned)),
                                              unsigned,
                                              std::uint32_t>;

для этого сегмента код:

uint32_t a = (...);
uint32_t b = a << 31;

поощрения a для типа без знака вместо типа со знаком используйте:

uint32_t b = a << 31u;

когда обе стороны << оператор является беззнаковым типом, то эта строка в 6.3.1.8 (c стандартный проект n1570) применяется:

в противном случае, если оба операнда имеют целочисленные типы со знаком или оба имеют целочисленные типы без знака, операнд с типом меньшего целочисленного ранга преобразования преобразуется в тип операнда с большим рангом.

---

проблема, которую вы описываете, вызвана тем, что вы используете 31 что это signed int type Итак, еще одна строчка в 6.3.1.8

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

сил a для повышения до знакового типа

---

обновление:

этот ответ неверен, потому что 6.3.1.1(2) (акцент мой):

...

если int может представить все значения исходного типа (Как ограничено по ширине, для битового поля), значение преобразуется в int; в противном случае он преобразуется в unsigned int. Они называются целое число специальные акции.58) Все остальные типы не изменяются целое акции.

и сноска 58 (Курсив мой):

58) целочисленные акции применяются только: как часть обычных арифметических преобразований, к некоторым выражениям аргументов, к операндам унарных операторов+, -, и ~ и к оба операнда операторов сдвига, как указано в соответствующих подпунктах.

так как происходит только целочисленное продвижение, а не общее арифметическое преобразование, используя 31u не гарантия a для преобразования в unsigned int как указано выше.