W dniu 2015-12-03 16:08, M.M. pisze:
> On Thursday, December 3, 2015 at 3:05:24 PM UTC+1, Tomasz Kaczanowski wrote:
>> W dniu 2015-12-03 15:00, M.M. pisze:
>>> On Thursday, December 3, 2015 at 2:34:00 PM UTC+1, Tomasz Kaczanowski wrote:
>>>> W dniu 2015-12-03 14:08, M.M. pisze:
>>>>> On Thursday, December 3, 2015 at 1:09:14 PM UTC+1, Tomasz Kaczanowski wrote:
>>>>>
>>>>>> i gdzieniegdzie będzie mały bum, bo *((int*)(buf+2)); może mieć zdziebko
>>>>>> inną zawartość, niż nam się wydaje,
>>>>>
>>>>> Nie rozumiem. W jakich sytuacjach może mieć inną zawartość? Na moje
>>>>> albo reprezentacja bitowa się zgadza, albo nie. Jeśli nie, to w
>>>>> ogóle nie można używać kopiowania bitów.
>>>>
>>>> Tam gdzie zmienne muszą mieć wyrównane adresy. O ile w przypadku
>>>> spakowanej struktury przy odczycie kompilator wykona za nas odpowiednie
>>>> operacje, to w takim przypadku, gdy rzutujesz dane spod adresu, mówisz
>>>> kompilatorowi "wiem co robię, nie wtrącaj się", a, że wynik może w takim
>>>> przypadku być inny, cóż...
>>>
>>> To przy operacji:
>>> *((int*)(buf+2))
>>> kompilator nie wygeneruje takiego samego kodu jak przy wypakowaniu
>>> inta przesuniętego o 2 bajty w strukturze? Myślałem że na danej
>>> platformie kompilator bezpiecznie przerzuci dane na wyrównany adres i
>>> dopiero potem zacznie operować na tych danych.
>>
>>
>> z doświadczenia wiem, że nie poprawne było dopiero
>>
>> int zmienna;
>> memcpy(zmienna, (buf+2), sizeof(int));
>
>
> Jeśli wcześniej było:
> memcpy( buf+2 ,&zmienna , sizeof(int) );
> To też nie widzę zagrożenia. Rozmawiamy rzecz jasna o zgodnym formacie
> na poziomie bitów.

Cały czas zakładam zgodność bitów i endianów, bo inaczej żadne z tych
nie byłoby prawidłowe.

> Gdy ktoś upakował dane przy pomocy memcpy, a potem odzyskuje przez:
> *((int*)(buf+2))
> to obawiam się, że nie zawsze zadziała, o ile się nie mylę, to zadziała
> tylko na bigendian.

Nie - to zadziała, tam, gdzie jedyne wyrównanie odnośnie adresów dla
zmiennych jest adres parzysty, a to nie musi być prawdą. Przykład
częściej wysypujący się, to jeśli pierwsza dana będzie char, a następna
int. Wtedy będzie nieparzysty adres i na większej ilości
systemów/sprzętów zadziała to nieprawidłowo. Endianowość może co
najwyżej zmniejszyć efekt w niektórych wypadkach, ale nie zagwarantuje
ogólnie poprawnego działania.

Oczywiście pomijam fakt, ze wszelkie struktury transportowe winno raczej
opisywać się przez int32_t itp, wtedy mamy przynajmniej wielkość
zagwarantowaną.


--
Kaczus
http://kaczus.ppa.pl