Как сделать структуру из битовых полей минимального размера? Опции

[inventor]

Подскажите опции, как сделать подобную структуру 1 байт длины
при всех попытках получается 4 байта

CODE

/**
* Состояние во время работы - 1 байт
*/
typedef struct {
unsigned device_in_runtime : 1;
unsigned acquisition_running : 1;
unsigned gps_sync_ok : 1;
unsigned queue_overrun : 1;
unsigned rsvd0:4;
} RUNTIME_STATE;

[kolobok0]

Подскажите опции, как сделать подобную структуру 1 байт длины
при всех попытках получается 4 байта
...

выравнивание на байт делали? всякие там прагма паки???

[SSerge]

А какого размера unsigned int? Правильно, 4 байта.
Хотите 8 бит - используйте соответствующий тип, например uint8_t.

[kolobok0]

не досмотр с меня под вечер..

CODE

typedef struct {
bool device_in_runtime : 1;
bool acquisition_running : 1;
bool gps_sync_ok : 1;
bool queue_overrun : 1;
bool rsvd0:4;
} RUNTIME_STATE;

тип правильный укажите...

Сообщение отредактировал kolobok0 - Sep 30 2015, 16:44

[zltigo]

при всех попытках получается 4 байта

Было-бы странно, если-бы после вашего ПРЯМОГО указания сделать структуру размером int, компилятор смог сделать что-то другое.

выравнивание на байт делали? всякие там прагма паки???

Дивная мысль - приказать паковать одинокий int. Интересно во что и с чем?

[scifi]

Было-бы странно, если-бы после вашего ПРЯМОГО указания сделать структуру размером int, компилятор смог сделать что-то другое.

Я немного разжую замечание коллеги.
А вы в курсе, что unsigned - это unsigned int? Вопрос номер два: а вы не пробовали написать unsigned char? Ну или uint8_t?

[ViKo]

Правильно колобок говорил: паки-паки... Никакие char в битовом поле ни на что не влияют. Задано поле 1 бит, таким и будет.

Ой! Посмотрел, как я пишу. Задаю везде uint8_t xxx : 1;

[kolobok0]

Правильно колобок говорил: паки-паки.....

там ТС юзает не битовые поля. если начнёт юзать - то паки собственно и не нужны.
ну по крайней мере у меня так иар ся ведёт...

[zltigo]

там ТС юзает не битовые поля. если начнёт юзать - то паки собственно и не нужны.

Что это написано? Не осилил

[inventor]

не досмотр с меня под вечер..

CODE

typedef struct {
bool device_in_runtime : 1;
bool acquisition_running : 1;
bool gps_sync_ok : 1;
bool queue_overrun : 1;
bool rsvd0:4;
} RUNTIME_STATE;

тип правильный укажите...

ставил и pragma pack(1) и
__attrib__ ((packed))
попробую завтра поменять unsigned на u8
меня сбило с толку что в борланде размер этой структуры
получился 1 байт
хотя то же стояло unsigned

[kolobok0]

ставил и ...

CODE

typedef struct {
bool device_in_runtime : 1;
bool acquisition_running : 1;
bool gps_sync_ok : 1;
bool queue_overrun : 1;
bool rsvd0:4;
} RUNTIME_STATE;

тупо скопируйте тот код что запостил я.
потом компильнитесь и посмотрите отличия от Вашего варианта...

Что это написано? Не осилил

конкретнее какие слова не понятны?

Сообщение отредактировал kolobok0 - Sep 30 2015, 19:50

[den_po]

sizeof(bool) не обязан быть 1

[inventor]

CODE

typedef struct {
bool device_in_runtime : 1;
bool acquisition_running : 1;
bool gps_sync_ok : 1;
bool queue_overrun : 1;
bool rsvd0:4;
} RUNTIME_STATE;

тупо скопируйте тот код что запостил я.
потом компильнитесь и посмотрите отличия от Вашего варианта...

конкретнее какие слова не понятны?

поменял unsigned на u8 - все стало правильно.
спасибо за подстказку.
единственное что непонятно, почему в борланде BCC32 все эти структуры
такого размера как мне надо!

[zltigo]

конкретнее какие слова не понятны?

К сожалению все . Не могу даже ухватиться за какую-то тень мысли

sizeof(bool) не обязан быть 1

Именно так! Зависит от платформы и компилятроа.

единственное что непонятно, почему в борланде BCC32 все эти структуры
такого размера как мне надо!

Потому, что Борланд с его феерической традиционной кривизной и наплевательством на стандарты. Сваяли в свое время некий "Паскаль" в отсутствие стандарта, и решили повторить "успех" с Си. Я начинал в свое время BCPP 1.0 - ну очень потом, когда поумнел, ругался.

[scifi]

Потому, что Борланд с его феерической традиционной кривизной и наплевательством на стандарты. Сваяли в свое время некий "Паскаль" в отсутствие стандарта, и решили повторить "успех" с Си. Я начинал в свое время BCPP 1.0 - ну очень потом, когда поумнел, ругался.

Я бы так не спешил. Вот читаю в стандарте про битовые поля и до конца понять не могу. Там практически всё "implementation-defined":

An implementation may allocate any addressable storage unit large enough to hold a bit-field.
If enough space remains, a bit-field that immediately follows another bit-field in a
structure shall be packed into adjacent bits of the same unit. If insufficient space remains,
whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is
implementation-defined. The order of allocation of bit-fields within a unit (high-order to
low-order or low-order to high-order) is implementation-defined. The alignment of the
addressable storage unit is unspecified.

Короче, там почти ничего не определено стандартом. Битовые поля отданы на откуп компиляторописателям.

[ViKo]

Похоже, битовое поле должно встраиваться в тот тип переменной, который указан. Если написали uint8_t, то, значит, в него.
Bool не катит, он может все 32 бита (int) оккупировать.

[scifi]

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

Нет, не похоже. Во всяком случае, в тексте стандарта я этого не увидел. Более того, стандарт допускает, что битовое поле может наложиться на соседнее. Так что это абсолютно непереносимая штука.
Но я не йурист, если что...

[ViKo]

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

Забить не полностью байт - это понимаю. Расположиться в двух соседних байтах - возможно. Добавляю дурных dummy битов на этот случай, для выравнивания. Но наложиться...? Это уж вряд ли.

[scifi]

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

[zltigo]

Короче, там почти ничего не определено стандартом. Битовые поля отданы на откуп компиляторописателям.

Но не замена ЯВНО указанного размера "юнита" int на восемь бит, как это делает по уверждению автора Борланд.

[scifi]

Но не замена ЯВНО указанного размера "юнита" int на восемь бит, как это делает по уверждению автора Борланд.

Пруф?
Я утверждаю обратное.
Там даже вот такое есть:

A bit-field shall have a type that is a qualified or unqualified version of_Bool, signed int,unsigned int, or some other implementation-defined type.

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

[zltigo]

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

А то, что дефиниции int, без разбивки его на биты, размер выделяется "соответствующий указанному типу" и не может быть изменен компиляторописателями где-то написано? Нет?
А зачем тогда ВООБЩЕ тип указывается ("bit-field shall have a type") в такой структуре, если он по Вашему мнению ничего не должен значить? Я битовыми полями пользуюсь десятки лет и на десяках компиляторов и платформ. Да, уровень стандартизации невысок , но на практике, при аккуратном четком описании структур, вылезает в реальности только порядк битов. Выделение явно указанному ТИПУ не его размера памяти есть чистый криминал.

[scifi]

А то, что дефиниции int, без разбивки его на биты, размер выделяется "соответствующий указанному типу" и не может быть изменен компиляторописателями где-то написано? Нет?

Написано:

A "plain" int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

А зачем тогда ВООБЩЕ тип указывается ("bit-field shall have a type") в такой структуре, если он по Вашему мнению ничего не должен значить?

ИМХО, только чтобы различать целое и bool. Ну и знак, естественно. Во всяком случае, из стандарта это следует.
Другое дело, что вот это всё "implementation-defined" позволяет использовать размер целого типа как указание компилятору, какими кусками выделять память под битовые поля. Но, повторюсь, это "implementation-defined".

[zltigo]

ИМХО, только чтобы различать целое и bool

Глупость. Хотя-бы по той железобетонной причине, что битовые поля существовали в стандарте тогда, когда никакого _Bool, как нативного типа, и близко не было и различать было просто нечего.

Написано:
Цитата
A "plain" int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

Наверное Вы что-то пропустили в цитате, ибо я что-то не увидел, что int допускается в структурах содержащих битовые поля МОЖНО выделять МЕНЬШЕ памяти, чем требуется для INT_MAX?
Или такого не написано? Тогда к чему цитата?

[scifi]

Наверное Вы что-то пропустили в цитате, ибо я что-то не увидел, что int допускается в структурах содержащих битовые поля МОЖНО выделять МЕНЬШЕ памяти, чем требуется для INT_MAX?
Или такого не написано? Тогда к чему цитата?

Написано, вы просто не стали читать. Напишу снова:

An implementation may allocate any addressable storage unit large enough to hold a bit-field.

По-моему, исчерпывающе. Никаких отсылок к размеру типа, используемого при объявлении битового поля. Можете возразить: "Да это же подразумевается, конечно!" На это я возражу, что если такие вещи будут подразумеваться, то и стандарт не нужен, всё ведь и так всем понятно и подразумевается.

[zltigo]

Можете возразить: "Да это же подразумевается, конечно!"

Это НЕ подразумевается это ПРЯМО указывается указанием ТИПА этого самого '"storage unit".

Никаких отсылок к размеру типа, используемого при объявлении битового поля.

Если требование указания ТИПА "storage unit" , не есть такая "отсылка", то что-же это такое Ну а то, что Вы процитировали это на самом деле СНЯТИЕ требования к компилятору паковать битовые поля из разных "storage unit" стык в стык, если количество биттов МЕНЬШЕ, чем задано типом "storage unit". Вот так просто.

[scifi]

Ну что ж, можно констатировать, что есть как минимум два мнения о том, что имелось в виду. Надо править текст стандарта, чтобы двух мнений не было.
Кстати, с моей интерпретацией согласны пейсатели книг:

Container size - If packing and straddling is not an issue, does the compiler reliably place a bit field within a container of the user-specified size? We cannot be sure, since the Spec. says an implementation can use "any addressable storage unit large enough" to accomodate the bit field.

Взято отсюда.

[zltigo]

Кстати, с моей интерпретацией согласны пейсатели книг:

Я бы не приимал априори, что писатели книг умнее Вас .

[scifi]

Я бы не приимал априори, что писатели книг умнее Вас .

Я также не принимал бы априори, что писатели книг глупее кого бы то ни было.

Кстати, а как насчёт техасских инструментов? Отсюда:

The declared type of a bit-field is the type that appears in the source code. To hold the value of a bit-field, the C and C++ standards allow an implementation to allocate any addressable storage unit large enough to hold it, which need not be related to the declared type. The addressable storage unit is commonly called the container type, and that is how we refer to it in this document. The container type is the major determinant of how bit-fields are packed and aligned.
C89, C99, and C++ have different requirements for the declared type:
C89 int, unsigned int, signed int
C99 int, unsigned int, signed int, _Bool, or "some other implementation-defined type"
C++ any integral or enumeration type, including bool

Кстати, получается, что стандарт C90 допускает только int, unsigned int, signed int для битовых полей, всё остальное не гарантируется. У меня под рукой нет текста C90, но охотно верю.
И вообще, если пошерстите гугл на предмет "any addressable storage unit", то увидите, что с вашей интерпретацией никто не согласен. Сдавайтесь

[zltigo]

Кстати, получается, что стандарт C90 допускает только int, unsigned int, signed int для битовых полей, всё остальное не гарантируется.

Да, не требуется к реализации компилятором. Значит, если компилятор не поддерживает, то будет ругаться. Если поддерживаетт, а неподерживающих, например, тот-же char, встречать не приходилось, то будет вести себя соответствии с заданным типом.

то увидите, что с вашей интерпретацией никто не согласен. Сдавайтесь

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

[esaulenka]

А можно ещё вопрос, раз уж битовые поля вспомнили?

На всех "ширпотребных" компиляторах начало битовой структуры кладётся в младшие биты? Или наоборот где-то есть?

[zltigo]

На всех "ширпотребных" компиляторах начало битовой структуры кладётся в младшие биты? Или наоборот где-то есть?

Есть и часто и в передлах одного компилятора - зависит от контроллера. Старшие-младшие биты прыгают вместе "endian".
У меня все такие места, если это важно, идут с контролем того чем и для чего компилируется. Но других проболем в реале в общем-то нет, ну кроме обычных с паковкой структур.

[esaulenka]

Под "ширпотребом" я подразумевал little-endian, конечно же.
ARM'ы всевозможные, x86, 8-битники какие-нибудь - типовой набор эмбеддера.


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

[Artem_Petrik]

Под "ширпотребом" я подразумевал little-endian, конечно же.
ARM'ы всевозможные, x86, 8-битники какие-нибудь - типовой набор эмбеддера.


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

STM8 вполне себе ширпотреб, и он big endian. Так что в лохматые годы углубляться вовсе не обязательно.

[ViKo]

STM8 вполне себе ширпотреб, и он big endian.

О как!? STM8 - прощайте!