Здравствуйте, Посторонним В., Вы писали:

ПВ>По сети я получаю пакет само собой в виде нетипизированного char-буфера. Формат пакета таков: в первых 4 байтах идет размер (unit32), потом уже сам пакет.

boost::uint32_t packetSize = *(boost::uint32_t*)(buf);

Есть ещё одна проблема, тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы, поэтому приравнивание лучше заменить на функцию.

Здравствуйте, Left2, Вы писали:

L>Интересно...
L>Это какие?

Например PPC, АФАИК

Здравствуйте, Посторонним В., Вы писали:

ПВ>После прочтения недавно обсуждавшейся темы про strict aliasing

Автор: McSeem2
Дата: 23.08.07

засомневался, правильно ли я делаю.
ПВ>По сети я получаю пакет само собой в виде нетипизированного char-буфера. Формат пакета таков: в первых 4 байтах идет размер (unit32), потом уже сам пакет.

Так скажем, с практической точки зрения тут всё будет работать, и при агрессивной оптимизации компилятора проблем из-за aliasing не возникнет, т.к. буфер у тебя константный и ты в него ничего не пишешь. Проблемы с aliasing возникают при модификациях буфера, т.к. возникают проблемы с выстраиванием зависимостей по данным.

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

С теоретической точки зрения... абстрагируемся от факта, что любая реальная программа (особенно работающая с сетью и потоками) — есть тонкое переплетение UB

Здравствуйте, Посторонним В., Вы писали:

ПВ>Вот сделал тестовый пример с невыровненным буфером. Выдает "ok" на MSVC8 и gcc4 с включенной в выключенной оптимизацией.

Платформа Win32 терпимо относится к невыровненному чтению/записи данных — разве что происходит некоторое снижение производительности. Но есть и такие платформы, на которых попытка невыровненного чтения/записи вызывает исключительную ситуацию.

ПВ>Или это пример, когда правильное поведение является частным случаем UB?

Именно.

Здравствуйте, Посторонним В., Вы писали:

ПВ>

ПВ>boost::uint32_t packetSize = *(boost::uint32_t*)(buf);
ПВ>

В общем случае (если ничего не знать о том, откуда берётся buf) есть потенциальная возможность для невыровненного доступа. Если buf — это указатель на буфер, выделенный malloc/new, или же указатель на массив объектов boost::uint32_t, то правильное выравнивание гарантируется.

Вариант с memcpy легален без оговорок, разве что приведение &packetSize к void* излишне.

Здравствуйте, remark, Вы писали:

R>Имхо, абсурдно тут идти против платформы
Почему против? А если сама платформа предоставляет такие возможности?

R>>>>>
R>>>
R>

Здравствуйте, remark, Вы писали:

R>Vain сказал: "тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы"
R>Вот я и хочу понять, как он может от компилятора зависеть.

Дык,
Во-первых, на 16-битной платформе 32-битный long (это, кстати, тоже зависит от компилятора; про разрядность long в стандарте не сказано, хотя есть соглашение разработчиков компиляторов) не влезает в аппаратуру, и его эндианность — снова воля компилятора.

Во-вторых, есть полноценные big-endian платформы, поэтому утверждение Vain'а — тождественно истинно.

R>

Хватит пить на работе!

После прочтения недавно обсуждавшейся темы про strict aliasing

Автор: McSeem2
Дата: 23.08.07

засомневался, правильно ли я делаю.
По сети я получаю пакет само собой в виде нетипизированного char-буфера. Формат пакета таков: в первых 4 байтах идет размер (unit32), потом уже сам пакет.
В данный момент я делаю так:

bool parseReceivedBuffer(const char* buf, size_t size)
{
  if (size < sizeof(boost::uint32_t))
    return false;
  boost::uint32_t packetSize = *(boost::uint32_t*)(buf);
  buf += packetSize;
  // дальше парсю сам пакет..
}

Насколько корректна выделенная строка?
А если сделать так

memcpy((void*)&packetSize, buf, sizeof(boost::uint32_t));

?

Здравствуйте, achp, Вы писали:

A>В общем случае (если ничего не знать о том, откуда берётся buf) есть потенциальная возможность для невыровненного доступа. Если buf — это указатель на буфер, выделенный malloc/new, или же указатель на массив объектов boost::uint32_t, то правильное выравнивание гарантируется.

aliasing и aligning

Автор: remark
Дата: 24.08.07

Здравствуйте, remark, Вы писали:

R>aliasing и aligning

Автор: remark
Дата: 24.08.07

Э... И чего? Совмещение миён здесь проблемой не является ни при каких обстоятельствах. А вот выравнивание под вопросом.

Здравствуйте, achp, Вы писали:

A>Здравствуйте, remark, Вы писали:

R>>aliasing и aligning

Автор: remark
Дата: 24.08.07

A>Э... И чего? Совмещение миён здесь проблемой не является ни при каких обстоятельствах. А вот выравнивание под вопросом.

Во-первых, вопрос про aliasing. Во-вторых, буфер-то он сам выделял, значит, наверное, в курсе на сколько он выровнен.

Здравствуйте, Vain, Вы писали:

V>Есть ещё одна проблема, тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы, поэтому приравнивание лучше заменить на функцию.

???

Есть такие компиляторы

Здравствуйте, remark, Вы писали:

V>>Есть ещё одна проблема, тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы, поэтому приравнивание лучше заменить на функцию.
R>???
Ну, в настройках думаю может быть вполне, к примеру, как выгружать/загружать в/из памяти short/int/long, это опять же зависит от платформы, только тут скорее уже C-компиляторы.
R>Есть такие компиляторы
Это вопрос или утверждение?

R>

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, remark, Вы писали:

V>>>Есть ещё одна проблема, тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы, поэтому приравнивание лучше заменить на функцию.
R>>???
V>Ну, в настройках думаю может быть вполне, к примеру, как выгружать/загружать в/из памяти short/int/long, это опять же зависит от платформы, только тут скорее уже C-компиляторы.

Верится с трудом.

R>>Есть такие компиляторы
V>Это вопрос или утверждение?

Это вопрос: Есть такие компиляторы?

R>>

Здравствуйте, remark, Вы писали:

V>>>Есть ещё одна проблема, тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы, поэтому приравнивание лучше заменить на функцию.
R>>???
V>Ну, в настройках думаю может быть вполне, к примеру, как выгружать/загружать в/из памяти short/int/long, это опять же зависит от платформы, только тут скорее уже C-компиляторы.
R>Верится с трудом.
Почему?

R>>>Есть такие компиляторы
V>>Это вопрос или утверждение?
R>Это вопрос: Есть такие компиляторы?
А почему нет?

R>>>
R>

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, remark, Вы писали:

V>>>>Есть ещё одна проблема, тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы, поэтому приравнивание лучше заменить на функцию.
R>>>???
V>>Ну, в настройках думаю может быть вполне, к примеру, как выгружать/загружать в/из памяти short/int/long, это опять же зависит от платформы, только тут скорее уже C-компиляторы.
R>>Верится с трудом.
V>Почему?

R>>>>Есть такие компиляторы
V>>>Это вопрос или утверждение?
R>>Это вопрос: Есть такие компиляторы?
V>А почему нет?

Имхо, абсурдно тут идти против платформы

R>>>>
R>>

Здравствуйте, remark, Вы писали:

R>Это вопрос: Есть такие компиляторы?

В принципе, а почему бы и нет? Если процессор чисто 16-битный — то запросто. Например, 8086 или PDP-11.
Порядок вордов в дворде там обуславливается только традициями и предпочтениями.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

R>>Это вопрос: Есть такие компиляторы?

К>В принципе, а почему бы и нет? Если процессор чисто 16-битный — то запросто. Например, 8086 или PDP-11.
К>Порядок вордов в дворде там обуславливается только традициями и предпочтениями.

А сложение как там работает?

Здравствуйте, remark, Вы писали:

К>>В принципе, а почему бы и нет? Если процессор чисто 16-битный — то запросто. Например, 8086 или PDP-11.
К>>Порядок вордов в дворде там обуславливается только традициями и предпочтениями.

R>А сложение как там работает?

Как нефиг делать.

; dx:ax - число в регистрах
; dword ptr[si] - число в памяти, адрес - в регистре si

add ax, word ptr [si+4] ; сложили младшие ворды
adc dx, word ptr [si+0] ; сложили старшие ворды с переносом

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

К>>>В принципе, а почему бы и нет? Если процессор чисто 16-битный — то запросто. Например, 8086 или PDP-11.
К>>>Порядок вордов в дворде там обуславливается только традициями и предпочтениями.

R>>А сложение как там работает?

К>Как нефиг делать.
К>

К>; dx:ax - число в регистрах
К>; dword ptr[si] - число в памяти, адрес - в регистре si

К>add ax, word ptr [si+4] ; сложили младшие ворды
К>adc dx, word ptr [si+0] ; сложили старшие ворды с переносом
К>

Этот код не может работать с разным порядком байт в слове.
Если add работает более чем с одним байтом, то ему *нужно* знать в каком порядке там лежат байты.
Или я совсем что-то не понимаю.
Ядро же должно знать из какого байта слова в какой делать перенос.

Здравствуйте, remark, Вы писали:

A>>Э... И чего? Совмещение миён здесь проблемой не является ни при каких обстоятельствах. А вот выравнивание под вопросом.

R>Во-первых, вопрос про aliasing.
Цитата:

После прочтения недавно обсуждавшейся темы про strict aliasing засомневался, правильно ли я делаю.
...
boost::uint32_t packetSize = *(boost::uint32_t*)(buf);
...

Что тут указвает на то, что вопрос именно про aliasing?
ИМХО вопрос о правильности вообще


R>Во-вторых, буфер-то он сам выделял, значит, наверное, в курсе на сколько он выровнен.
Ключевое слово "наверное". Лично я сильно сомневаюсь, что кто-то будет специально следить за выравниванием char-буфера.
Конечно, если буфер выделяется с помощью new[], то проблем с выравниванием не будет. А если как-то по-другому? А если buf указывает внутрь другого char-буфера?
Конечно о том, как оно в данном случае на самом деле, пусть скажет автор.

Здравствуйте, remark, Вы писали:

R>Этот код не может работать с разным порядком байт в слове.
R>Если add работает более чем с одним байтом, то ему *нужно* знать в каком порядке там лежат байты.
R>Или я совсем что-то не понимаю.
R>Ядро же должно знать из какого байта слова в какой делать перенос.
Так перед любой операцией операнды неявно в регистры должны сначало копироваться, а в регистрах всегда представлено в какомто одном виде, разница имеется только при загрузке и выгрузке.

R>

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, remark, Вы писали:

R>>Этот код не может работать с разным порядком байт в слове.
R>>Если add работает более чем с одним байтом, то ему *нужно* знать в каком порядке там лежат байты.
R>>Или я совсем что-то не понимаю.
R>>Ядро же должно знать из какого байта слова в какой делать перенос.
V>Так перед любой операцией операнды неявно в регистры должны сначало копироваться, а в регистрах всегда представлено в какомто одном виде, разница имеется только при загрузке и выгрузке.

А операнды в памяти?

Пример хоть один кто может указать?

R>>

Здравствуйте, remark, Вы писали:

R>Этот код не может работать с разным порядком байт в слове.

А я и не говорил, что порядок байтов big endian.
В данном случае получилась смешанная эндианность. big endian слов (рукодельный), little endian байтов в слове (аппаратный).

Правда, я не знаю, зачем делать именно так. Ну, вообразим, что для совместимости с кодом, писанным в стародавние времена, когда об аппаратной поддержке 32-битной арифметики ещё не задумывались.
Вот сделали же в паскале зоопарк плавающих типов без оглядки на сопроцессор и ieee. Ибо какая разница, что программно эмулировать. Шестибайтовая вещь-в-себе.

А вот пример другой смешанной эндианности — это битмапы с глубиной цвета 8 или меньше. (Про hicolor/truecolor не знаю, надо смотреть).

Здравствуйте, remark, Вы писали:

R>Верится с трудом.
R>Это вопрос: Есть такие компиляторы?

Про компиляторы не скажу, но есть такие процессоры, где endian -- это атрибут кода. Какой флажок на сегмент выставишь, такой и будет...

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

R>>Этот код не может работать с разным порядком байт в слове.

К>А я и не говорил, что порядок байтов big endian.
К>В данном случае получилась смешанная эндианность. big endian слов (рукодельный), little endian байтов в слове (аппаратный).

К>Правда, я не знаю, зачем делать именно так. Ну, вообразим, что для совместимости с кодом, писанным в стародавние времена, когда об аппаратной поддержке 32-битной арифметики ещё не задумывались.
К>Вот сделали же в паскале зоопарк плавающих типов без оглядки на сопроцессор и ieee. Ибо какая разница, что программно эмулировать. Шестибайтовая вещь-в-себе.

К>А вот пример другой смешанной эндианности — это битмапы с глубиной цвета 8 или меньше. (Про hicolor/truecolor не знаю, надо смотреть).


Если реализовывать работу с числами больше слова, то в принципе можно сделать "смешанную" эндианность.
Но что бы компилятор шёл против нативной эндианности на уровне слова — не верю.

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, remark, Вы писали:

A>>>Э... И чего? Совмещение миён здесь проблемой не является ни при каких обстоятельствах. А вот выравнивание под вопросом.

R>>Во-вторых, буфер-то он сам выделял, значит, наверное, в курсе на сколько он выровнен.
B>Ключевое слово "наверное". Лично я сильно сомневаюсь, что кто-то будет специально следить за выравниванием char-буфера.
B>Конечно, если буфер выделяется с помощью new[], то проблем с выравниванием не будет. А если как-то по-другому? А если buf указывает внутрь другого char-буфера?
B>Конечно о том, как оно в данном случае на самом деле, пусть скажет автор.

Честно говоря, я не хочу знать про то, как буфер был веделен. То есть, конечно, знаю, что дело было так:

std::vector<char> rxBuf(maxSize);
size_t rxBytes = recv(soсk, &rxBuf[0], maxSize, 0);
...

но не хочу от этого зависеть.

Здравствуйте, remark, Вы писали:

R>Пример хоть один кто может указать?

Тебе нужен пример из жизни, или пример кода?
Пример кода я привёл.

Байты в словах — в естественном для процессора виде (здесь — little), слова в дворде — в договорном. Вот договорились, что они big — значит, и будут big.

Перенос — естественно, из младшего слова в старшее. Осуществляется программно. Не одной инструкцией, а двумя.
А то, где именно младшее слово относительно старшего хранится — что в памяти, что в регистрах — исключительно хозяйское дело.
Например, dx:ax. Вот в паре ah:al вольностей нет, там ah старший. Впрочем, в паре dx:ax тоже вольностей мало (они участвуют в 16/32-битном умножении и делении). Но скажем, вторая пара регистров, bx:cx или cx:bx.

В жизни бывает удобно, чтобы эндианность байтов и слов совпадала. Тогда длинная арифметика работает одинаково что над массивом байтов, что над массивом слов.
Однако, смешанная эндианность тоже встречается.
Вот специально для этого и используют конвенции: обмениваться данными — в зафиксированном формате (network endianness — это абсолютный big endian), а обрабатывать — в платформенно-зависимом.

Здравствуйте, Посторонним В., Вы писали:

ПВ>Честно говоря, я не хочу знать про то, как буфер был веделен. То есть, конечно, знаю, что дело было так:
ПВ>

ПВ>std::vector<char> rxBuf(maxSize);
ПВ>size_t rxBytes = recv(soсk, &rxBuf[0], maxSize, 0);
ПВ>...
ПВ>

ПВ>но не хочу от этого зависеть.

Ну так и используй memcpy во избежание всяких неожиданностей. Тем более что стандарт гарантирует корректность этой операции (3.9/2)

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

R>>Пример хоть один кто может указать?

К>Тебе нужен пример из жизни, или пример кода?
К>Пример кода я привёл.

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

Здравствуйте, remark, Вы писали:

R>Если реализовывать работу с числами больше слова, то в принципе можно сделать "смешанную" эндианность.
R>Но что бы компилятор шёл против нативной эндианности на уровне слова — не верю.

А где он там идёт против?
В исходном сообщении речь была про boost::uint32_t, но про платформу умолчали.
Для 16-битной платформы нет нативной 32-битной эндианности вообще: какую компилятор захочет, такую и сделает.
Поэтому, в общем случае, код проблематичный.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

R>>Если реализовывать работу с числами больше слова, то в принципе можно сделать "смешанную" эндианность.
R>>Но что бы компилятор шёл против нативной эндианности на уровне слова — не верю.

К>А где он там идёт против?
К>В исходном сообщении речь была про boost::uint32_t, но про платформу умолчали.

Речь уже давно не об исходном сообщении
Речь об этом:
http://www.rsdn.ru/forum/message/2634657.1.aspx

Автор: Vain
Дата: 27.08.07

Vain сказал: "тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы"

Вот я и хочу понять, как он может от компилятора зависеть.

Здравствуйте, remark, Вы писали:

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

Это только для 8-битных платформ. Но там С++ ещё поискать надо...

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

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

К>Это только для 8-битных платформ. Но там С++ ещё поискать надо...

Порядок байтов в слове, которое состоит из одного байта... хммм... интересно...

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

R>>Vain сказал: "тип int/long может быть и не little endian, это в общем зависит от компилятора и платформы"
R>>Вот я и хочу понять, как он может от компилятора зависеть.

К>Дык,
К>Во-первых, на 16-битной платформе 32-битный long (это, кстати, тоже зависит от компилятора; про разрядность long в стандарте не сказано, хотя есть соглашение разработчиков компиляторов) не влезает в аппаратуру, и его эндианность — снова воля компилятора.

К>Во-вторых, есть полноценные big-endian платформы, поэтому утверждение Vain'а — тождественно истинно.

Хорошо. Будем считать вопрос исчерпаным.

R>>

К>Хватит пить на работе!

Здравствуйте, remark, Вы писали:

К>>Это только для 8-битных платформ. Но там С++ ещё поискать надо...

R>Порядок байтов в слове, которое состоит из одного байта... хммм... интересно...

Ну, нашёл к чему прикопаться. Хорошо, двухбайтовый "ворд".

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, remark, Вы писали:

К>>>Это только для 8-битных платформ. Но там С++ ещё поискать надо...

R>>Порядок байтов в слове, которое состоит из одного байта... хммм... интересно...

К>Ну, нашёл к чему прикопаться. Хорошо, двухбайтовый "ворд".

Двухбайтовый "ворд" на 8-битной платформе... хммм... интересно...

Здравствуйте, remark, Вы писали:

R>Двухбайтовый "ворд" на 8-битной платформе... хммм... интересно...

А ты как думаешь! Длина адреса (у i8080, к примеру) скольки-битная? Так что всё честно.
Кстати, это может послужить критерием эндианности.

Но не везде. У i8086 — 32-битный адрес состоит из сегмента и смещения. На стеке (в командах push cs; call ___; ....; retf) они оказываются в порядке ip;cs, т.е. little endian, однако ручные упражнения со стеком (например, при реализации long jmp) не показатель. Мы можем прочитать длинный адрес из дворда как нам угодно и затем эмулировать long jmp правильной последовательностью команд (push HIADDR; push LOADDR; retf). Ну а чтение/запись по far указателю сопровождается загрузкой в один из сегментных регистров, что опять даёт нам возможности для произвола.

Здравствуйте, Bell, Вы писали:

B>Ключевое слово "наверное". Лично я сильно сомневаюсь, что кто-то будет специально следить за выравниванием char-буфера.
B>Конечно, если буфер выделяется с помощью new[], то проблем с выравниванием не будет. А если как-то по-другому? А если buf указывает внутрь другого char-буфера?

Вот сделал тестовый пример с невыровненным буфером. Выдает "ok" на MSVC8 и gcc4 с включенной в выключенной оптимизацией. Или это пример, когда правильное поведение является частным случаем UB?

#include <iostream>
#include "boost/cstdint.hpp"

int main()
{
   char alignedBuf[5];// проверял - адрес alignedBuf кратен 4 байтам  
   alignedBuf[0] = 'a';
   boost::uint32_t expected = 123;
   memcpy(alignedBuf + 1, &expected, sizeof(boost::uint32_t));
   char* nonalignedBuf = alignedBuf + 1;
   boost::uint32_t actual = *(boost::uint32_t*)(nonalignedBuf);
   std::cout << ((actual == expected) ? "ok\n" : "nok\n");
   return 0;
}

E>Про компиляторы не скажу, но есть такие процессоры, где endian -- это атрибут кода. Какой флажок на сегмент выставишь, такой и будет...
Интересно...
Это какие?