LINUX.ORG.RU

Может, хватит употреблять такие вещества?

anonymous
()

1 бит = 0x24

Ты бит с байтом перепутал? o_O

KRoN73 ★★★★★
()
Ответ на: комментарий от sergv

Да, конечно, почему нет?

Кстати, union-ы лучше, чем приведение типов указателей (gcc с -O2 может и нули показать в более сложных случаях, man strict aliasing).

Kiborg ★★★
()
Ответ на: комментарий от anonymous

Да? Ну может и так, я на всякий случай упомянул :)

Kiborg ★★★
()
Ответ на: комментарий от Kiborg

Спасибо!

Читал просто как-то про union и геморой с выравниваниями. Вот с тех пор (uchar *) и пользую... Решил спросить - может у кого опыт применения в реальной жизни есть.

sergv
()
Ответ на: комментарий от nanoolinux

Да, вроде как если платформа такая злобная, что адресовать умеет только по 4-хбайтной границе, только сдвиганием в явном виде можно получить куски. Но так не узнаешь, что там реально в памяти в каком порядке.

svu ★★★★★
()

тебе что нужно?

если знать как байты (2ух или четырёх или восьмибайтного инта хранятся ) то присваиваеш в нулевой области (на 256) уникальные байты а потом по известному адрессу читаеш как инт и смотриш что за число прочиталось из этого понятно станет младшие впереди , старшие впереди , или как в сфэйлившем по этому 32битном pdp11(который был биг эндиан на 16битах и убейся об стену от произвола и сиюминутного решения на 32 битах) или вообще перестановка 8 элиментов(их как раз 8!) - вдуг у этого конкретного имбедеда так НУЖНО.

qulinxao ★★☆
()

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

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Все наоборот. PDP-11 хранит байты в слове в LE-порядке, а две с половиной 32-разрядных инструкции обращаются к словам внутри двойного слова как BE.

anonymous
()
Ответ на: комментарий от anonymous

ок . фишка про которую считаю важно помнить и знать что нашлись идиоты и/или практическая необходимость скрестить 2 разных направления размещения старшей и младшей половины при разбещении 4 байт.

и всё таки pdp11 вроде старший байт слова хранил по меньшему адресу

короче если 4 байта в арабской записи по основанию 256 записать как x01x02x03x04 то в памяти оно лежало как (x02x01x04x03 либо x03x04x01x02) в отличии от чистого младшие вперёд(BE?) (x04x03x02x01) и чистого старшие раньше(x01x02x03x04)

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

так как x86 хранит слово как меньший адресс -младший байт поэтому и называется LE

qulinxao ★★☆
()
Ответ на: комментарий от anonymous

ок в результате
int a[2]={1,0}
*((long*)(a+0)) умножает на 256 что печально ибо тоже самое с char2int не катит.

qulinxao ★★☆
()
Ответ на: комментарий от svu

Да, вроде как если платформа такая злобная, что адресовать умеет только по 4-хбайтной границе

это какая такая платформа?

waker ★★★★★
()
#include <stdio.h>

unsigned char get_byte(int x, unsigned char n)
{
    return ((unsigned int)x >> (n << 3)) & 0xff;
}

int main(void)
{
    int i = 2780;

    for (int b = 0; b < 4; ++b)
        printf("%dB = %d\n", b, ((unsigned char*)&i)[b]);

    for (int b = 0; b < 4; ++b)
        printf("%dB = %d\n", b, get_byte(i, b));

    return 0;
}
$ ./a.out
0B = 220
1B = 10
2B = 0
3B = 0
0B = 220
1B = 10
2B = 0
3B = 0
220 * (2 ^ 8) ^ 0 + 10 * (2 ^ 8) ^ 1 + 0 * (2 ^ 8) ^ 2 + 0 * (2 ^ 8) ^ 3 == 2780

Гуглить нужно словосочетание «get bit/byte from integer».

quasimoto ★★★★
()
Ответ на: комментарий от svu

sizeof(char) по стандарту 1, sizeof от массива размера N N*sizeof от элемента, так что это уже проблемы компилятора, как он будет доставать тебе байт, пусть сдвиги вставляет.

Yareg ★★★
()
Ответ на: комментарий от anonymous

В arm нельзя читать невыровненное четырёхбайтное значение (на самом деле и в x86, хоть формально и можно, но лучше не надо), а байт можно считать по любому адресу.

Yareg ★★★
()
Ответ на: комментарий от buddhist

Существует ненулевая вероятность, что char занимает не один байт.

можно CHAR_BIT проверить

dimon555 ★★★★★
()
Ответ на: комментарий от qulinxao

и всё таки pdp11 вроде старший байт слова хранил по меньшему адресу

Доки почитай, норкоман.

anonymous
()
Ответ на: комментарий от anonymous

вики оказалось достаточно.

в любом случае финт ушами в разнонаправленности порядка байт в слове и слов в двойном - очень дорогая ошибка дизайна.

qulinxao ★★☆
()
Ответ на: комментарий от sergv

Вопрос есть к знатокам: такая конструкция корректно порядок байт для BE/LE покажет?

да, конечно. Тут две переменные в одной и той же памяти.

ЗЫЖ за использование таких конструкций в продакшене бьют канделябрами по голове. А посмотреть - посмотри...

drBatty ★★
()
Ответ на: комментарий от sergv

Читал просто как-то про union и геморой с выравниваниями.

в моём примере никакого гемора не будет, инфа 146%.

drBatty ★★
()
Ответ на: комментарий от buddhist

Существует ненулевая вероятность, что char занимает не один байт.

число бит в байте не играет роли. Union будет работать, даже если в байте 6 или 66 бит. Дело в том, что sizeof(char) === 1 по определению. При этом, sizeof(int) указывает длину int в char'ах, если в int 100 бит, а в char 66 бит, то sizeof(int) == 2. И моя структура будет работать правильно. Как компилятор будет доставать 66и битные char'ы - его проблемы, но дырок между ними НЕ будет, потому union будет выдавать то, что есть.

drBatty ★★
()
Ответ на: комментарий от exception13

существуют архитектуры способные адресовать только слово.

это проблема компилятора. Либо в нём word === char, либо пусть двигает слова, доставая char'ы andом.

drBatty ★★
()
Ответ на: комментарий от drBatty

...в продакшене бьют канделябрами по голове.

Повеселило ;-)

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

sergv
()

бит с байтом - да перепутал, спасибо за достоиные ответы.

mordovorot
() автор топика

Иногда во время чтения лоровского /d/, у меня складывается впечатление, что это норкоманы барыжат веществами, обмениваясь стеганографическими сообщениями..

LamerOk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.