Корректен ли такой casting? - C/C++

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, 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), а обрабатывать — в платформенно-зависимом.

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

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

ПВ>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-битной эндианности вообще: какую компилятор захочет, такую и сделает.
Поэтому, в общем случае, код проблематичный.

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

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

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

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

Речь уже давно не об исходном сообщении

Речь об этом:
http://www.rsdn.ru/forum/message/2634657.1.aspx

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

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

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

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

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

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

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

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

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

R>

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

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

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

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

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

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

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

R>>

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

К>Здравствуйте, 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 указателю сопровождается загрузкой в один из сегментных регистров, что опять даёт нам возможности для произвола.

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, 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 -- это атрибут кода. Какой флажок на сегмент выставишь, такой и будет...
Интересно...
Это какие?

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

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

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

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

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

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

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

Именно.

	От:	Кодт
	Дата:	27.08.07 10:26
	Оценка:

	От:	Erop
	Дата:	27.08.07 10:42
	Оценка:

От:	remark	http://www.1024cores.net/
Дата:	27.08.07 10:42
Оценка:

	От:	Посторонним В.
	Дата:	27.08.07 11:19
	Оценка:

	От:	Кодт
	Дата:	27.08.07 11:32
	Оценка:

	От:	achp
	Дата:	29.08.07 10:56
	Оценка:	2 (1)