Форма 16-битных слов из структуры

Question

Форма 16-битных слов из структуры

0

Поэтому я работаю над созданием эхо-запроса ICMPv4 и решил запустить мою собственную структуру для хранения пакета. Чтобы сделать идентификацию пакета легко идентифицировать в wirehark, я решил поместить abcde в поле данных.

struct icmpPacket{
    u_int8_t icmp_type:8, icmp_code:8;
    u_int16_t icmp_checksum:16, icmp_id:16, icmp_seqnum:16;
    char icmp_data[6]; //cheat a little bit, set the field just large enough to store "abcde";
    } __attribute__((aligned (16))) icmppckt; // icmp has an 8 byte header + 6 bytes of data

Я застрял в том, как заставить компилятор читать структуру как серию 16-битных слов

Wusiji 10 июль 2014, в 11:05

Источник

0

msgstr "как заставить компилятор читать структуру как последовательность 16-битных слов" . Что вы имеете в виду? Вы можете использовать union но я не знаю, имеете ли вы это в виду.
Adriano Repetti 10 июль 2014, в 08:49
0

Я хотел бы передать структуру в функцию, которая принимает u_int16_t * в качестве параметра
Wusiji 10 июль 2014, в 08:50
0

Вы можете использовать union чтобы иметь два вида этой структуры. В противном случае простое reinterpret_cast<u_int16_t*>(&yourStruct) (в C ++ или ((u_int16_t*)&yourStruct) в C) выполнит свою работу.
Adriano Repetti 10 июль 2014, в 08:53
2

@AdrianoRepetti Использование результата reinterpret_cast<u_int16_t*>(&yourStruct) для доступа к объекту - неопределенное поведение, поскольку оно нарушает строгие правила наложения имен.
T.C. 10 июль 2014, в 09:18
0

@AdrianoRepetti Предварительное условие: «Если объединение стандартных макетов содержит несколько структур стандартных макетов, которые имеют общую начальную последовательность». Массив даже не стандартная структура размещения.
T.C. 10 июль 2014, в 13:44
0

@T.C.массив будет разделен как есть структурное расположение (если инициализируется сначала массив). структуры не могут быть разделены, если их участники не совпадают ...
Adriano Repetti 10 июль 2014, в 13:49
0

@AdrianoRepetti Единственный стандарт C ++, который гарантирует доступ w / r / t через неактивный член объединения, состоит в том, что если у вас есть 1) объединение стандартных макетов, которое 2) имеет несколько структур стандартных макетов в качестве членов, которые 3) имеют общий инициал последовательность, и 4) объединяющий ток содержит одну из этих структур, затем 5) разрешается проверять общую начальную часть любой из них. Массив не является структурой, тем более структурой стандартной компоновки, и, следовательно, это положение не применяется.
T.C. 10 июль 2014, в 13:54
0

@T.C.no, в C согласно сноске 78a §6.5.2.3 # 3 : «Если элемент, используемый для доступа к содержимому объекта объединения, не совпадает с элементом, который последний раз использовался для хранения значения в объекте, соответствующий часть представления объекта значения повторно интерпретируется как представление объекта в новом типе, как описано в 6.2.6 (процесс, иногда называемый «наказанием типа»). Это может быть представление ловушки ». , В C ++ это все еще не определено (вопрос в этом случае должен быть помечен как C или C ++).
Adriano Repetti 10 июль 2014, в 14:40

Показать ещё 6 комментариев

Теги:

c++

c

struct

2 ответа

Ещё вопросы

msgstr "как заставить компилятор читать структуру как последовательность 16-битных слов" . Что вы имеете в виду? Вы можете использовать union но я не знаю, имеете ли вы это в виду.
Я хотел бы передать структуру в функцию, которая принимает u_int16_t * в качестве параметра
Вы можете использовать union чтобы иметь два вида этой структуры. В противном случае простое reinterpret_cast<u_int16_t*>(&yourStruct) (в C ++ или ((u_int16_t*)&yourStruct) в C) выполнит свою работу.
@AdrianoRepetti Использование результата reinterpret_cast<u_int16_t*>(&yourStruct) для доступа к объекту - неопределенное поведение, поскольку оно нарушает строгие правила наложения имен.
@AdrianoRepetti Предварительное условие: «Если объединение стандартных макетов содержит несколько структур стандартных макетов, которые имеют общую начальную последовательность». Массив даже не стандартная структура размещения.
@T.C.массив будет разделен как есть структурное расположение (если инициализируется сначала массив). структуры не могут быть разделены, если их участники не совпадают ...
@AdrianoRepetti Единственный стандарт C ++, который гарантирует доступ w / r / t через неактивный член объединения, состоит в том, что если у вас есть 1) объединение стандартных макетов, которое 2) имеет несколько структур стандартных макетов в качестве членов, которые 3) имеют общий инициал последовательность, и 4) объединяющий ток содержит одну из этих структур, затем 5) разрешается проверять общую начальную часть любой из них. Массив не является структурой, тем более структурой стандартной компоновки, и, следовательно, это положение не применяется.
@T.C.no, в C согласно сноске 78a §6.5.2.3 # 3 : «Если элемент, используемый для доступа к содержимому объекта объединения, не совпадает с элементом, который последний раз использовался для хранения значения в объекте, соответствующий часть представления объекта значения повторно интерпретируется как представление объекта в новом типе, как описано в 6.2.6 (процесс, иногда называемый «наказанием типа»). Это может быть представление ловушки ». , В C ++ это все еще не определено (вопрос в этом случае должен быть помечен как C или C ++).

T.C. · Answer 1 · 2014-07-10T08-33-00.000Z

Стандартный способ для этого - через memcpy:

icmpPacket packet = { /* ... */ };
uint16_t buf[sizeof(icmpPacket) / sizeof(uint16_t)];
memcpy(buf, &packet, sizeof(icmpPacket));
/* Now use buf */

Современные компиляторы достаточно умны, чтобы оптимизировать их соответствующим образом, фактически не выполняя вызов функции. См. Примеры с clang и g++).

Общее расширение компилятора позволяет использовать союзы, хотя это неопределенное поведение в стандарте C++:

union packet_view{
    icmpPacket packet;
    uint16_t buf[sizeof(icmpPacket) / sizeof(uint16_t)];
};
icmpPacket packet = { /* ... */ };
packet_view view;
view.packet = packet;
/* Now read from view.buf. This is technically UB in C++ but most compilers define it. */

Использование reinterpret_cast<uint16_t*>(&packet) или его эквивалент C нарушит строгие правила псевдонимов и приведет к неопределенному поведению. §3.10 [basic.lval]/p10 стандарта C++:

Если программа пытается получить доступ к сохраненному значению объекта с помощью glvalue, отличного от одного из следующих типов, поведение не определено:

динамический тип объекта,

cv-квалифицированная версия динамического типа объекта,

тип, аналогичный (как определено в 4.4) для динамического типа объекта,

тип, который является подписанным или неподписанным типом, соответствующим динамическому типу объекта,

тип, который является подписанным или неподписанным типом, соответствующим версии с динамическим типом объекта cv,

совокупный или тип объединения, который включает один из вышеупомянутых типов среди его элементов или нестатических членов данных (включая рекурсивно элемент или нестатический элемент данных субагрегата или содержащегося объединения),

тип, который является (возможно, cv-квалифицированным) типом базового класса динамического типа объекта,

char или unsigned char type.

Аналогично, в §6.5/p7 из C11 говорится:

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

тип, совместимый с эффективным типом объекта,

квалифицированную версию типа, совместимую с эффективным типом объекта,

тип, который является подписанным или неподписанным типом, соответствующим эффективному типу объекта,

тип, который является подписанным или неподписанным типом, соответствующим квалифицированной версии эффективного типа объекта,

совокупный или союзный тип, который включает один из вышеупомянутых типов среди его членов (включая рекурсивно, член субагрегата или объединенного объединения) или

тип символа.

Приведение -1 не является неопределенным поведением: определяется структура памяти структуры, а также структура массива (в противном случае даже memcpy не будет работать). Это запрещено оптимизацией компилятора (которая может быть отключена локально). tp для профсоюзов допускается в некоторых случаях (см. другой комментарий).
@AdrianoRepetti Нет, строгий псевдоним обязателен стандартом.
прочитайте последний пункт: «тип символа». Тогда: char * может "получить доступ" к чему угодно. short * может «получить доступ» к char * (и наоборот). Тогда я не вижу причин, по которым короткий * не может "получить доступ" к структуре * ...
@AdrianoRepetti Да, это не UB, если вы приведете к типу char * (подписанный / неподписанный) и разыщите его. Я не совсем уверен, откуда у вас идея, что стандарт гарантирует, что вы можете на законных основаниях привести char * к short * и почтить его - вы, очевидно, не можете, потому что char * может даже не быть правильно выровнен. По вашей логике, строгое правило псевдонимов потеряло бы весь смысл.
массивы являются «смежно выделенными подобъектами элементов», потому что §8.3.4 . Выравнивание массива задается выравниванием структуры. Вы правы в одном: это часть стандарта, а не реализации. Вы можете отключить строгий псевдоним или ... пройти двойное приведение к пустоте * (разрешено, как ответил Спектре). Часть об объединении все еще наполовину неверна: в C это разрешено (но не в C ++, см. Комментарий к вопросу).
@AdrianoRepetti Я не говорил, что наказание по типу через союзы незаконно в C. Я сказал, что это UB в C ++. И двойное приведение через void * - просто неясный способ написания reinterpret_cast , и он не устраняет никаких проблем с наложением.
Плохо, я не видел, чтобы вы ограничивали обсуждение объединения с C ++. Двойное приведение (некрасиво, я должен признать) позволяет избежать этой проблемы просто потому, что псевдоним void * разрешен, а компилятор будет считать, что правило недействительно. Менее элегантный, чем явный (но непереносимый) __attribute __ (may_alias).
@AdrianoRepetti reinterpret_cast между двумя типами указателей определяется как static_cast<cv T2*>(static_cast<cv void*>(expression)) - то есть через двойное приведение через void . Возможно, некоторые реализации предполагают использование псевдонимов при явном двойном приведении, но это не гарантируется стандартом.
Они должны принять псевдоним с первым приведением к void * (или к char *).
@AdrianoRepetti Не совсем. Например, g ++ до сих пор выдает строгое предупреждение о псевдонимах даже при приведении к void * .
Так плохо для g ++! Позвольте мне перефразировать «они ДОЛЖНЫ - в соответствии со спецификацией - псевдоним».
@AdrianoRepetti Нет, они не должны. Они должны предполагать, что void * или char * могут иметь псевдоним, но когда вы приводите void * обратно к указателю на тип (не char), тогда компилятор может предположить, что этот указатель не имеет псевдонима указателя другой тип.
Почему? При первом приведении первый указатель будет считаться псевдонимом. Последующий второй акт не должен изменить это.
@AdrianoRepetti Потому что стандарту все равно, как вы получили указатель. Строгое правило псевдонимов определяется в терминах доступа к сохраненному значению объекта одного типа через glvalue другого типа. Он основан на типах, а не на каком-то «порочном» правиле. Независимо от того, вставляете ли вы приведение к void * или нет, разыменование конечного указателя все равно дает вам glvalue другого типа, и стандарт говорит, что с перечисленными исключениями это неопределенное поведение для доступа к сохраненному значению через него.
@AdrianoRepetti Поэтому как GCC и лязг будет компилировать этот код в memset даже если код , как написано имеет P ступенчатость &P .
Вы меня убедили, я согласен на кастинг! (даже если на самом деле GCC не жалуется, если я это делаю ...)

Spektre · Answer 2 · 2014-07-10T06-54-00.000Z

вы можете использовать 16-битные указатели для этого

но вам нужно добавить выравнивание в 1 байт элементов структуры !!!

в C++ вы можете сделать это следующим образом:

#pragma pack(1)
struct icmpPacket
    {
    u_int8_t icmp_type:8, icmp_code:8;
    u_int16_t icmp_checksum:16, icmp_id:16, icmp_seqnum:16;
    char icmp_data[6]; //cheat a little bit, set the field just large enough to store "abcde";
    } icmppckt; // icmp has an 8 byte header + 6 bytes of data
WORD *picmppckt16=(WORD*)((void*)&icmppckt);
#pragma pack()

измените WORD на 16-битный тип данных, который ваш компилятор знает...