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.


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.


Pozdrawiam