А кто тебе сказал, что buf всегда будет выровнен по размеру unsigned long? Многие архитектуры невыровненный доступ к словам вообще не разрешают. На ia32 оно просто тормозить будет, на MIPS или на Sparc трапнется.

anonymous

А кто тебе сказал, что buf всегда будет выровнен по размеру unsigned long?

Если ты про выделение памяти, buf размечается через malloc в 1024 байта. В программе, в том числе много такого кода:

char *buf;
*((unsigned long *)buf) = htonl(some_long_value);
*((unsigned short *)(buf+sizeof(unsigned long))) = htons(some_short_value);

Если ты про выделение памяти, buf размечается через malloc в 1024 байта. В программе, в том числе много такого кода:

Сам по себе (buf) может быть и выровнен как надо, а вот (buf + sizeof(что_то)) уже может залезть на границу.

Нет, про выравнивание. То есть, значение адреса buf должно быть кратно 4 или 8 (что там у тебя long). Это далеко не всегда так, потому и необходимо использовать memcpy.

Если buf выровнен по sizeof(что-то), то и buf+sizeof(что-то) будет так же выровнен.

А вот если там протокол хитрый, например, идут byte + byte + word + byte, то этот самый word будет невыровненным.

Вообще, по хорошему, за любую конструкцию вида *((some_integral_type *)buf) = ... надо отрывать руки. Потому как это, согласно стандарту, undefined behaviour в случае невыровненного указателя. Поскольку buf определен как char*, он может быть выровнен как угодно.

бро, это или херня какая-то или у тебя хитрожопый memcpy

if( memcpy

man memcpy

void *memcpy(void *dest, const void *src, size_t n);

ВОЗВРАЩАЕМЫЕ ЗНАЧЕНИЯ

Функция memcpy() возвращает указатель на dest.

Если buf выровнен по sizeof(что-то), то и buf+sizeof(что-то) будет так же выровнен.

А вот если там протокол хитрый, например, идут byte + byte + word + byte, то этот самый word будет невыровненным.

Да, я неточно выразился.

Отрицательные указатели? Это что-то новое.

anonymous

Вообще, по хорошему, за любую конструкцию вида *((some_integral_type *)buf) = ... надо отрывать руки.

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

anonymous

Поскольку buf определен как char*, он может быть выровнен как угодно.

каким образом выровнять, чтобы работало и на x86 и на MIPS? По сути сейчас в buf хранятся только uint16_t и uint32_t.

на структуры

За пакованые структуры тоже надо руки отрывать. Не все компиляторы такие умные, кто-то может и UB получить.

каким образом выровнять, чтобы работало и на x86 и на MIPS? По сути сейчас в buf хранятся только uint16_t и uint32_t.

Ты не можешь записать 16bit и после сразу 32bit таким образом как ты хочешь. Вот если бы были только 16 или только 32 бита - другое дело. А так - только memcpy, только побайтовая запись в буфер.

За пакованые структуры тоже надо руки отрывать. Не все компиляторы такие умные, кто-то может и UB получить.

У нас вполне конкретный компилятор gcc. Программа только под linux.

Ты не можешь записать 16bit и после сразу 32bit таким образом как ты хочешь.

На данный момент программа написана именно так и всё работает и на x86 и на MIPS. Объясни конкретнее.

«Именно так» - это как? С кастованием char* к long*? Не верю, оно трапнется.

И это не самое умное решение, на gcc рассчитывать. UB - оно такое, сегодня работает, завтра перестанет.

fighting the lemmings

Не верю, оно трапнется.

Тебе видеозапись с компиляцией и запуском предоствить?

Кстати, еще от ОС зависит - некоторые это прерывание корректно обрабатывают (например, OpenVMS на Альфе обрабатывал, а Digital Unix трапался). Но в любом случае это адски медленно. Так что не выпендривайся и делай как стандарт велит.

Кстати, еще от ОС зависит

может ещё на ресурсе об ОС Linux обсудим компиляцию при помощи Visual Studio 2012 под WIndows 8 на arm?

Так что не выпендривайся и делай как стандарт велит.

Ни одной ссылки от тебя не было. Только mironov_ivan запостил Fighting the Lemmings

gcc далеко не единственный компилятор под linux. И я уж молчу про всякие embedded.

Пример проблем с невыровненным доступом: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html

gcc далеко не единственный компилятор под linux. И я уж молчу про всякие embedded.

Кароч, понял, ты вообще не в теме. Я уточнял вполне конкретную архитектуру, ОС и компилятор. Ты толи слепой, толи конченный тролль. И продолжаешь сочинять страшилки про никому ненужные архитектуры и вспоминать что было 10 лет назад.

Если ты не в теме ненадо парить мозг.

Ну, короче, ты быдлокодер. Тех мразей, кто пишет под «конкретную архитектуру, ОС и компилятор» надо кастрировать ржавыми ножницами без наркоза. И, кстати, лошара, производительность невыровненного доступа - говно даже на x86. Он, конечно же, работает, на раз в десять медленнее чем memcpy. Ну да быдлокодеров обычно и это не останавливает.

Похоже нашел то что надо: http://www.leonerd.org.uk/code/libpack/

Посоветовали на другом ресурсе, может кому-то пригодится.

Ну, короче, ты быдлокодер.

ТРО-ЛО-ЛО - ШКО-ЛО-ЛО

Про выравнивание уже сказали, но по-настоящему сочные ошибки можно получить вот из-за этого: http://dbp-consulting.com/tutorials/StrictAliasing.html

Хотелось бы готовое решение, для упаковки структур, т.к. изобретение велосипедов ненужно. Нашел вот ещё что http://code.google.com/p/protobuf-c/.

Про выравнивание уже сказали,

дело в том что, ещё нужно конвертировать в сетевую(или любую другую) нотацию чтобы все нормально работало при передаче по сети между разными host системами(big/little endian)

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

О черт.... тысячи/сотни тысяч раз обсуждалось КАК сделать что бы хтонлы и нтохлы работали кроссплатформенно в твоем коде.

В любом мало мальски приличном учебнике по С это описано...

Ну да, это все вместе с условной компиляцией :)

Хотя можно и без нее, но это так - повыеживаться :)

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

Поехавший? Это в памяти платформы они д. б. выровнены, ввод/вывод — только поэлементно и никак иначе.

ввод/вывод — только поэлементно и никак иначе.

Ну зачем же так сразу... boost/serialization например есть.

Оп, а ты вообще знаком с выравниванием, ну с термином таким?

плюсую, и пох до скора.

Jetty

О черт.... тысячи/сотни тысяч раз обсуждалось КАК сделать что бы хтонлы и нтохлы работали кроссплатформенно в твоем коде.

Каким образом запаковать структуру при помощи htonl htons? Да я знаю, сейчас ты предложешь очередной самописный велосипед. Например передавать как строку и использовать терминатор.

У кого-нибудь есть отзывы о protobuf ?

У нас вполне конкретный компилятор gcc. Программа только под linux.

Убил бы.

So slow...