Старший бит в битовом поле для целого

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

Ты наркоман. Сделай по-человечески, без структур и жутких макросов. Примерно так:

int i9m_1 = read_u8() >> 7;
int i9m_0 = read_u8();
int value = i9m_1 ? i9m_0 : -i9m_0;

#define _GET_8_i09(signal)

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

Это мне так приходит по сети. 9 бит в bigendian формате

У меня таких макросов >7000 строк. Для разной длинны переменной и положения первого бита. Но можно будет сделать такой вариант специально для случая когда число знаковое и первый кусочек в один бит.

Однобитовые поля надо делать unsigned; но с битовыми полями лучше вообще не связываться, если не можешь в любое время дня и ночи назвать порядок битовых полей при заданном сочетании компилятора и архитектуры :)

Уж сколько раз твердили миру - распаковывый то что «приходит по сети» из байт сдвигами и бинарными операциями, забудь про битовые поля и pragma pack.

а ntohs/ntohl уже не в моде? велосипедисты хреновы.

Вообще-то он именно это и делает.

да, но велосипедить-то на какого фейхоа?

Что велосипедить? ntohs научился с 9 битами работать и правильно обрабатывать padding?

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

утверждение было голословно и не привязано к 9 битам. но даже с 9 битами: и с чего это там битовые поля в упакованных структурах не подошли?

Попробуй ответить на простой вопрос: какая стандартная функция разберёт тебе 9 бит в знаковое целое?

используют настройки текущей архитектуры

Если что, разбор байтового потока никак не зависит от текущей архитектуры.

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

Чтобы говорить что «надо» и «не надо», нужно сначала быть компетентным в обсуждаемом вопросе.

Это тут не работает

Надо!

Вот примеры структур, которые надо разбирать. Из интересного, они содержат поля и в бигэендиан и в литлэндиан формате. И разбирать их надо на обоих архитектурах (BE & LE):

• test_msg_0
• test_msg_1
• test_msg_2
• test_msg_3

Собственно это у меня уже есть. Остался один косячок с этим битиком.

Ничего не понятно. Там числа не непрерывно по битам идут?

Непрерывно :). Но, например, на PowerPC. А читать надо на интеле

В твоих примерах видны только сообщения в network-byte-order, где ты там little-endian увидел?

те, поля название которых заканчивается на i (intel) - LE, m (motorola) - BE. Например test_msg_0 - все LE. А tst_msg_2 содержит и те, и те. Случай редкий, но на всякий случай хочется его предусмотреть.

А по-моему нет. Они разнесенны в адрессном пространстве, но всё же все поля NBO (msg2):

• синее: ntohl(((data[1]&15)<<2)|((data[2]&3)>>6))
• зелёное: ntohl(((data[3]&1)<<8)|data[4])
• оранжевое: ntohl(((data[6]&1)<<8))|data[5])

И если честно, я бы их так и шинковал.

PS: хотя, глянув на другие сообщения, может быть я и не прав... меня смущает немного розовое и синее поле в msg1 — биты все nbo, а вот порядок байт (кусков) — фиг знает.

С распаковкой/упаковкой у меня проблем нет. Есть описание все этих структур в специальном формате и есть кодогенератор, который генерит структуры и код для парсинга в обе стороны на обоих платформах. И это работает. Волнует именно один бит.

Это не работает!

Там же нарисованы стрелочки и даже подписан MSB (Most Significant Bit). Например, зеленое - ntohl не нужен. В 3 байте и так старший бит. Другое дело, что если в этом бите -1 то надо заполнить 1 все остальные старшие биты. А приведенные операции с байтами это не делают.

Не совсем по теме, но вдруг пригодится... А у тебя такое хитрое число одно, или дофига других двоичных данных для чтения? Если вдруг последнее, то не хочешь ли посмотреть в сторону Kaitai Struct?

Это CAN шина. И большинсто таких структур придумываем не мы, а производитель. Есть текстововое описание вида

BO_ 2147501122 TEST_MSG_2: 8 Vector__XXX
 SG_ i9m : 24|9@0- (1,0) [0|0] "" Vector__XXX
 SG_ i9i : 40|9@1- (1,0) [0|0] "" Vector__XXX
 SG_ u6m : 11|6@0+ (1,0) [0|0] "" Vector__XXX

«24|9@0-» расшифровывается так - Начинается с бита 24, длинна 9 бит, 0-интел, знаковое.

Такое ощущение, что вы озадачены обеспечением собственной job security, нежели решением проблемы. Поскольку код на макросах и на битовых полях кроме вас вряд ли кто-то сможет сопровождать.

В самих описаниях сообщений протокола нет ничего сложного. Если эти данные нужно распаковать в какие-то нормальные структуры для работ с ними в программе, то все это делается элементарно: берем n бит из текущего байта, добавляем к ним k бит из следующего байта, потом еще m бит из следующего байта и т.д. Никакой завязки на endianess и порядок расположения битовых полей в вашем компиляторе на вашей архитектуре.

Считается, что знаковое однобитное целое не имеет смысла, нет таких задач, для которых оно понадобится. Нафига целое с диапазоном значений (-1, 0)? Но если мне понадобится, то я выключу это предупреждение. Но MISRA и др. требования? А как на счет того, что тебе прилетает 9-ти битовое знаковое число, а не однобитовое? На мой взгляд, в данном случае надо сначала вычитать все байты, привести их порядок к нужному, сдвинуть и расширить знаковый бит. А у тебя начинается со знака, а потом склеивается. Это не красиво.

Я б так запилил, конечно memcpy еще добавить вместо тупого приведения типа и присвоения, отвязать от gcc и посолить C++ по вкусу:

#include <stdint.h>
#include <stdio.h>
#include <endian.h>

#define u6m_SWAB
#define u6m_OFFSET 1
#define u6m_SHIFT  6
#define u6m_BITS   6
#define u6m_SIZE   16
#define u6m_TYPE   uint16_t
#define u6m_UTYPE  uint16_t

#define i9m_SWAB   be16toh
#define i9m_OFFSET 3
#define i9m_SHIFT  0
#define i9m_BITS   9
#define i9m_SIZE   16
#define i9m_TYPE   int16_t
#define i9m_UTYPE  uint16_t

#define i9i_SWAB   le16toh
#define i9i_OFFSET 5
#define i9i_SHIFT  0
#define i9i_BITS   9
#define i9i_SIZE   16
#define i9i_TYPE   int16_t
#define i9i_UTYPE  uint16_t

#define GET(d, f) ({\
        union {\
            struct {\
                f##_TYPE a:f##_BITS;\
            } a;\
            f##_UTYPE b;\
        } t;\
        t.b = f##_SWAB(*(f##_UTYPE*)((uint8_t*)(d) + f##_OFFSET)) >> f##_SHIFT;\
        t.a.a;})

int main () {
    uint8_t a[] = {1,2,3,4,5,6,7,8,9,10};
    printf ("%d\n", (int)GET (a, i9m));
    printf ("%d\n", (int)GET (a, i9i));
    printf ("%d\n", (int)GET (a, u6m));
}

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