> :) я в таком комитете не состою

Я бы удивился если опеннетчика в ISO занесло. Это про ISO было если что :))

>> Простой вопрос: сколько байтов ЭТО в памяти жрет?
> там же нет необходимости в выравнивании, "степень двойки" ведь говорили они. :\

Я вроде простой вопрос задал. К сожалению комитет придурков так построил стандарт что на этот вопрос нет хорошего ответа. И это грабли. Что еще хуже, контроль над их ручкой тоже квазинестандартными вендорскими расширениями делается. Про ABI vs struct даже и упоминать неудобно.

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

Или представьте себе насколько красивее был бы код если бы поля пакета "в провод" можно было вписывать как изменение полей struct. Но из-за вооооон того фактора этот фортель если и работает то только местами, с больщими оговорками, а такой код - напрочь непортабельный. И даже так все же иногда делают, даже почтенные фирмы типа ARM какого или STMicro. "Ахренли, с вот этими компилерами работает же!".

Представляете - у ARM совершенно нормально определить "железку" чипа в духе

typedef some_hw_t struct {
volatile uint16_t reg1; 
volatile uint16_t reg2_field1:11; 
volatile uint16_t reg2_field2:5; 
} some_hardware_t

...и обычно это - работает. Хоть ниоткуда не следует что обязано. В этом примере у железки 2 16-бит регистра, при том второй доступен как 2 битовых поля, 11 и 5 битов. Современные компилеры даже так то чекнут что туда адекватное число вписывают.

Если попытаться загнать 50 в .reg2_field2 (скорее ->reg2_field2 ибо инстанс железки заводится как указатель на базовый адрес железки) - который 5-битный - компилер выдаст на это варнинг, ибо максимум который 2^5 может представить это 32. И это так то клево и круто. Но совершенно непортабельно и то что это работает - в общем то случайность. И по части битов, и по части align, там сразу два фэйла в 1 примере.

Т.е. в принципе это есть, это работает, код красивый и даже компилер малость чекает вменяемость того что вписывают в битовые поля. Проблема только в том что работа этого кода - случайность. Шаг в сторону и...

>> и компилер сделает "что-то"?
> во как О_о, ругаем язык или компилер?

Комитет придурков, за то что не удосужились менее отшибленые спеки ЯП сделать. Где например вон то поведение будет чем-то гарантированным а аспекты типа align - подконтрольными. В этом смысле Zig по моему допер вкатить явный атрибут struct что оно packed. А может и хруст.

>> числа в 1 u32 может быть куда эффективнее по генерируемому коду и скорости операций.
> На всех ли архитектурах?

1) Большинство того что поддерживает линух минимум 32 а сейчас скорее 64 бита.
2) Компилер обычно предвычисляет все что можно оформить константой и это будет один load 32 бит константы.
3) Вгруз 32 бит константы как правило не является проблемной операцией для 32 бит и тем более 64 бит платформ.
4) В случае продвинутых оптимизеров типа LTO это порой может быть сделано из чужих частей, если подхоящее уже было где-то. В этом месте компилер может дать мастеркласс любителю асма, вспомнив что кило кода назад в тот регистр подходящую константу уже, давайте-ка реюзнем. А человек потеряется в треке регистров на длинную дистанцию.

И да, одна из траблов с struct кроме голимого их определения и align "от фонаря" - то что компилер может иногда сделать не очень хороший код. Особенно - с битовыми полями. Там где это не важно - красота API может перевесить. Но это не тот случай. И тут может выйти не халявно по коду или памяти в горячем куске. А это хреново.

С другой стороной макросами можно халявное компилтайм формирование этого всего.
Скажем нечто в духе

#define MAKE_U32(hi16,lo16) ((hi16) << 16) | ((lo16) & 0xFFFF)
#define DECODE_LO16(a) ((a) & 0xFFFF)
#define DECODE_HI16(a) (((a) >> 16) & 0xFFFF)
uint32_t a = MAKE_U32(0x1020,0x3040); // Same as a = 0x10203040

Примечание: так не стоит делать без хорошей нужды. Ибо макросы в си это некие грабли. Зато все ЭТО может быть (и почти всегда будет) compile-time предвычислениями. А в реальный код это все пойдет как заранее посчитанные константы, т.е. вон та математика - на фазе компила, а не в рантайм. При том можно сохранить логическое биение на части. Это слабая и более дурная форма того что плюсеры называют constexpr. Вот тут код может быть очень эффективный и - лучше чем с struct, и по части памяти куда предсказуемее, u32 это u32, сильно меньше загонов чем struct vs align.

При желании к вон тому в принципе можно компил тайм верификацию приделать, скажем что hi16/lo16 не менее 0 и не более 65535. И попытки дать макро левак завалят компил. В сабже можно посмотреть как именно такое сделать (да, забавно что макросы могут быть ассертом времени компила "до кучи").

NB: продвинутые глобальные оптимизеры типа LTO иногда создают забавные результаты - казалось бы неудачный код может внезапно оказаться самым эффективным. Может зависеть от порядка кода, это затрагивает глобальные оптимизации типа реюза ранее вгруженых констант для иного блока кода.

> лишь спрашиваю - зачем вы это делаете именно таким способом, а не иначе.

Обычно сишники делают что-то странно выглядящее только если это имело некий технический пойнт. В этом случае пойнт - размещение в памяти (vs выравнивание) и (возможно) менее эффективный код для работы с struct ибо возможны, вот, загоны с выравниванием. А заодно возможно и с clamp математики до 16 битов под u16. Ну а 32 битное число - предмет заметно более простой...

> А мне вовсе ничего делать не надо :)

А, ну понятно, не ошибается тот кто ничего не делает, так то удобно но говорят есть нюанс :)