Следует ли использовать приведение для усечения длинной переменной?

Я думаю, что оба будут генерировать один и тот же двоичный код. Поскольку первое решение более читабельно, я бы использовал это. Вам просто нужно быть уверенным, что uint8 - это 8-но на всех платформах (я думаю, что это так)

Спасибо, @jaudo, я тоже в этом направлении.

Примечание: следует отдавать предпочтение стандартным stdint.h типам, таким как uint8_t, а не создавать свои собственные.

ИМО, если цель состоит в том, чтобы замаскировать, маска слова понятнее, чем любое (магическое) число.

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

Кроме того, бросок делает потерю точности явно преднамеренной. Многие компиляторы могут выдавать предупреждение о потере точности, что может быть крайне важно. (Я думаю о нубах, которые настолько определенный, что «size_t и указатели на самом деле просто unsigned int...)

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

@supercat Достаточно плохо, чтобы случайно сместить данные в бит знака, независимо от формата UB и подписи.

@Lundin: В нотации с дополнением до двух знаковый бит - это просто сокращение для «состояния этого бита и бесконечного числа битов слева». Значение -3 представляет собой бесконечное число единиц, за которыми следует 01. Возможно, удобнее думать о 32-разрядном значении с дополнением до двух как о составленном из бесконечного числа нулей или единиц, за которыми следует ровно 31 бит, но бесконечное количество единиц, за которыми следуют еще 29, а затем 01, то же самое, что бесконечное количество единиц, за которыми следует 01.

@Lundin: единственный раз, когда может возникнуть какая-либо аномалия, будет в случаях, когда сдвиг весь номер, включая начальные единицы или нули, приведет к чему-то, что не имеет формы «бесконечное количество единиц или нулей, за которыми следует 31 отдельный биты". Я не уверен, почему вы думаете, что есть что-то «случайное»: о смещении части бесконечной последовательности единиц в бит, представляющий бесконечную последовательность единиц.

@supercat Потому что на 16-битной машине многие программисты считают, что uint8_t u8=0x80; ... u8 << 8; даст результат 32768, а не -32768. И что (u8<<8) >>8 даст 0x80, а не 0xFF80. Это известный источник багов, так что спорить нет смысла.

@Lundin: В этом сценарии поведение будет отличаться от умножения степени двойки. Какое это имеет отношение к сдвигу влево отрицательных чисел в случаях, когда поведение C89 было бы эквивалентно умножению степени двойки?

Это и ваш комментарий об использовании обоих решений WET удовлетворяют, спасибо @chux

AFAICT (variable >> 8) & 0xFFu даст один и тот же результат независимо от того, является ли сдвиг арифметическим или логическим, если int имеет ширину не менее 16 бит (что, как я полагаю, гарантирует стандарт).

@IlmariKaronen Размер переменной для этого не имеет значения, только ее подпись. Если значение отрицательное, вы получаете поведение, определяемое реализацией. Одним из примеров такого сломанного кода может быть unsigned char u = 0; ... ~u >> n;

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

@Lundin, возможно, стоит отметить, что ваш первый набор рекомендаций предполагает, что chunk_lsb и chunk_msb сами по себе имеют тип, эквивалентный uint8_t. Это неясно из вопроса - «8-битные фрагменты» OP могут храниться в переменных, имеющих более широкий тип или подписанный.

@IlmariKaronen: Если бы авторы Стандарта требовали поведения с нулевым заполнением или расширением знака, но существовала некоторая платформа, где какое-то другое поведение было бы более полезным, обязательное поведение с нулевым заполнением или расширением знака могло бы сделать C менее полезно на этой платформе. Единственные ситуации, когда было бы лучше, если бы Стандарт предписывал эти два конкретных поведения, были бы, если такая платформа действительно существует, или создатель компилятора чувствует себя намеренно странным. Первый случай лучше всего подходит для нет, определяющего поведение...

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

Не согласен с использованием (uint8_t) применить и маску в chunk_lsb = (uint8_t) (variable & 0xFFu);. Приведения всегда достаточно, чтобы заглушить предупреждения. Маска лучше программирует. Но оба ВЛАЖНЫЙ. Кроме того, мне очень нравится ответ.

@Lundin, Джон Боллинджер: я действительно точно указал, что это переменные неподписанный, и в этом конкретном случае chunk_lsb и chunk_msb являются uint8 (uint8_t, отсюда и приведение), извините, если это было неясно