memcpy() v C99

Pátek Duben 27 02:27:00 CEST 2018

> Viac urcite pojedna o probleme z pohladu normy wek :)

Nepojedna, rozobrali ste to vycerpavajuco. Len doplnim, ze podobne ako bolo
treba najst ten link na stackoverflow, aj tam je taky zmateny popis
problemu, ze treba ist k starsiemu tam odkazovanemu prispevku dotycneho,
aby sa dalo pochopit, ze ho zmiatlo C99 6.5#6 kde sa zavadza pojem
"effective type".

Pre vysvetlenie som si zasiel k Derekovi Jonesovi, ten sa o tom pomerne
rozsiahlo (a tiez pre smrtelnika nie prilis pochopitelne) rozpisuje, ale
podstata je ta, ze aby sa nejako dal ramec optimalizatoru, ktory sa snazi
zistit, co vsetko moze urobit s objektom na ktory ukazuje nejaky smernik,
tak sa zavadza ten pojem "efektivneho typu" - a potom sa moze
predpokladat, ze dva smerniky ukazujuce na objekty rozdielnych typov (ine
nez void* a char* + varianty) neukazuju na ten isty objekt a z toho
odvodit optimalizacie. No a diskutovana veta hovori, ze ak sa priradi
nejaka hodnota do "nespecifikovaneho" smernika pomocou memcpy/memset, tak
v tom okamihu ma odkazovany objekt rovnaky efektivny typ, ako mal objekt
na ktory odkazoval zdrojovy smernik.

If a value is copied into an object having no declared type using
memcpy or memmove, or is copied as an array of character type, then the
effective type
of the modified object for that access and for subsequent accesses that do
not modify the
value is the effective type of the object from which the value is copied,
if it has one.

Tento odstavec sa teda vobec netyka nejakej nedefinovanej alebo
implementacne definovanej vlastnosti - tie v tom priklade samozrejme su, v
tom, ze sa memcpy robi medzi objektami ktore mozu mat skutocne dva
rozdielne typy s roznou fyzickou reprezentaciou v pamati; co sa vsak tyka
toho "efektivneho typu", ten sa pri prvom memcpy neprejavi, lebo tam je
uplne jasny ten efektivny typ - je to explicitne uint32_t kedze to je
explicitne dany typ cieloveho objektu; a u toho druheho memcpy nastane
prave "vznik" toho implicitneho "efektivneho typu", ale s tym sa zase nic
nerobi (az kym nepride ku konverzii pri vyhodnoteni vysledku, ale to je uz
nieco ine). Toto su dokazy, ze ten povodny dotazovatel na stackoverflow je
z toho uplne zmateny; netreba si toho teda lamat hlavu.

wek

----- Original Message ---------------

Subject: Re: memcpy() v C99
   From: "Milan B." <milan at bastl.sk>
   Date: Fri, 27 Apr 2018 01:50:54 +0200
     To: hw-list at list.hw.cz

This is a cryptographically signed message in MIME format.

--===============7691879131774750314==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="------------ms020707010406040900090904"

This is a cryptographically signed message in MIME format.

--------------ms020707010406040900090904
Content-Type: multipart/alternative;
 boundary="------------65F4E85C1116A1E9C801A0A9"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------65F4E85C1116A1E9C801A0A9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

No tak som si tu diskuziu nasiel, ked uz ste=C2=A0 sa nepodelili o link -=
 je=20
to toto?=20
https://stackoverflow.com/questions/35951539/type-agnostic-memcpy-in-c99

Pride mi ze tu - v pripade jednoduchych typov, ktore maju navyse rovnaku =

binarnu interpretaciu - nejde o technicky problem ale o formalny problem =

ohladne efektivneho typu (to je typ, ktory je podla nazoru alebo odhadu=20
kompilatora v pamati ulozeny) a pravidiel, ktore su v tom priklade=20
porusene. Problem je len v tom, ze sa datam nanucuje efektivny typ=20
uint_32 bez ohladu na to, co si o efektivnom type mysli nadradena funkcia=
=2E

Ak by mali odlisnu binarnu interpretaciu (napr. long ma 64 bitov, alebo=20
druhe pole by bolo pole float-ov) tak problem je uz aj technicky, kedze=20
efektivny typ sa nasilne meni bez toho, aby sa prisposobila binarna=20
reprezentacia dat

A problem nie je s memcpy, memcpy stale kopiruje byte po byte. Mam=20
dojem, ze autor problemu nieco nepochopil (je to naznacene v diskuzii=20
dalej).

Odporucam pozriet http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.p=
df

Viac urcite pojedna o probleme z pohladu normy wek :)

-m-

On 27.04.2018 0:00, Stano wrote:
> Endian je znamy a je to little endian. Prevsetky pouzite typy
> sizeof(unsigned long) =3D 4
> sizeof(unsigned) =3D 4
> sizeof(uint32_t) =3D 4
>
> Rovnako problem vie byt zo zarovnanim pamate (ale to tuna odpada)
> To comu nechapem je prave ze to nemusi dat ocakavany vysledok pre=20
> tento pripad 4 a 7 ani ked su splnene vsetky tieto podmienky.
> A prave to je nieco co nechapem a zaujima ma kde este moze byt=20
> problem. Akurat mam tu smolu alebo stastie ze sa mi nedari ten stav=20
> vyvolat a teda neviem sa pozriet do asm co compiler vymyslel ked to=20
> nefunguje.
>
> On 26. 4. 2018 21:59, Milan B. wrote:
>> On 26.04.2018 21:46, Milan B. wrote:
>>>
>>> =C2=A04,1
>>
>> Oprava: 6+2^32
>>
>> -m-
>>
>>
>>
>>
>> _______________________________________________
>> HW-list mailing list=C2=A0 -=C2=A0 sponsored by www.HW.cz
>> Hw-list at list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>
> _______________________________________________
> HW-list mailing list=C2=A0 -=C2=A0 sponsored by www.HW.cz
> Hw-list at list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list

--------------65F4E85C1116A1E9C801A0A9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix"><br>
      No tak som si tu diskuziu nasiel, ked uz ste=C2=A0 sa nepodelili o =
link
      - je to toto?
      <a class=3D"moz-txt-link-freetext" href=3D"https://stackoverflow.co=
m/questions/35951539/type-agnostic-memcpy-in-c99">https://stackoverflow.c=
om/questions/35951539/type-agnostic-memcpy-in-c99</a><br>
      <br>
      Pride mi ze tu - v pripade jednoduchych typov, ktore maju navyse
      rovnaku binarnu interpretaciu - nejde o technicky problem ale o
      formalny problem ohladne efektivneho typu (to je typ, ktory je
      podla nazoru alebo odhadu kompilatora v pamati ulozeny) a
      pravidiel, ktore su v tom priklade porusene. Problem je len v tom,
      ze sa datam nanucuje efektivny typ uint_32 bez ohladu na to, co=C2=A0=

      si o efektivnom type mysli nadradena funkcia.<br>
      <br>
      Ak by mali odlisnu binarnu interpretaciu (napr. long ma 64 bitov,
      alebo druhe pole by bolo pole float-ov) tak problem je uz aj
      technicky, kedze efektivny typ sa nasilne meni bez toho, aby sa
      prisposobila binarna reprezentacia dat <br>
      <br>
      A problem nie je s memcpy, memcpy stale kopiruje byte po byte. Mam
      dojem, ze autor problemu nieco nepochopil (je to naznacene v
      diskuzii dalej).<br>
      <br>
      Odporucam pozriet <a class=3D"moz-txt-link-freetext" href=3D"http:/=
/">http://</a><cite class=3D"iUh30"><a class=3D"moz-txt-link-abbreviated"=
 href=3D"http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf">www.o=
pen-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf</a></cite><br>
      <br>
      Viac urcite pojedna o probleme z pohladu normy wek :)<br>
      <br>
      -m-<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      On 27.04.2018 0:00, Stano wrote:<br>
    </div>
    <blockquote type=3D"cite" cite=3D"mid:5AE24C12.2000504 at gmail.com">End=
ian
      je znamy a je to little endian. Prevsetky pouzite typy
      <br>
      sizeof(unsigned long) =3D 4
      <br>
      sizeof(unsigned) =3D 4
      <br>
      sizeof(uint32_t) =3D 4
      <br>
      <br>
      Rovnako problem vie byt zo zarovnanim pamate (ale to tuna odpada)
      <br>
      To comu nechapem je prave ze to nemusi dat ocakavany vysledok pre
      tento pripad 4 a 7 ani ked su splnene vsetky tieto podmienky.
      <br>
      A prave to je nieco co nechapem a zaujima ma kde este moze byt
      problem. Akurat mam tu smolu alebo stastie ze sa mi nedari ten
      stav vyvolat a teda neviem sa pozriet do asm co compiler vymyslel
      ked to nefunguje.
      <br>
      <br>
      On 26. 4. 2018 21:59, Milan B. wrote:
      <br>
      <blockquote type=3D"cite">On 26.04.2018 21:46, Milan B. wrote:
        <br>
        <blockquote type=3D"cite">
          <br>
          =C2=A04,1
          <br>
        </blockquote>
        <br>
        Oprava: 6+2^32
        <br>
        <br>
        -m-
        <br>
        <br>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        HW-list mailing list=C2=A0 -=C2=A0 sponsored by <a class=3D"moz-t=
xt-link-abbreviated" href=3D"http://www.HW.cz">www.HW.cz</a>
        <br>
        <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Hw-list at list=
=2Ehw.cz">Hw-list at list.hw.cz</a>
        <br>
        <a class=3D"moz-txt-link-freetext" href=3D"http://list.hw.cz/mail=
man/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a>
        <br>
      </blockquote>
      <br>
      _______________________________________________
      <br>
      HW-list mailing list=C2=A0 -=C2=A0 sponsored by <a class=3D"moz-txt=
-link-abbreviated" href=3D"http://www.HW.cz">www.HW.cz</a>
      <br>
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Hw-list at list.h=
w.cz">Hw-list at list.hw.cz</a>
      <br>
      <a class=3D"moz-txt-link-freetext" href=3D"http://list.hw.cz/mailma=
n/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a>
      <br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>

--------------65F4E85C1116A1E9C801A0A9--

--------------ms020707010406040900090904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CxUwggUnMIIED6ADAgECAhBaOXInlDUU0qv438ByXhenMA0GCSqGSIb3DQEBCwUAMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzA1MjMwMDAw
MDBaFw0xODA1MjMyMzU5NTlaMB8xHTAbBgkqhkiG9w0BCQEWDm1pbGFuQGJhc3RsLnNrMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtVPJqzmOIsOzaAqK0QpQI4/l731a2gab
3eAYKHVT823MJ0EJJgSzKM3osZmAXH3J3xqKZ2NSBkMZipEoLVue/7uw9CdaKGo4EjzCIX7v
7dVohzNobEuAcVkgmrQFqfcsgfonugqkcuU5ltN7ovwN7Gfm8miY1EZN5Gu9VWvO08CF43nH
nlaNKDU/HDQpCGjGUsXxz3qjGclojSKE3Aa8e4piSdUEyniOYHbsnSr5qHgrQOASAA5D9Lq2
Z4y/B0+fK7EOpTJwwj7PfjhbdKND0/a3Xlt02J/y0ImUH66eKsVvSC+kykbFXgwVj4gGTZaC
Xouzz+sYDxMRiVk124NUaQIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgf
PStxSF7Ei8AwHQYDVR0OBBYEFFODeGnJ9aGQ6Qq2NdeDp5tlzzZaMA4GA1UdDwEB/wQEAwIF
oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglg
hkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC
ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0
cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRT
ZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8v
Y3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy
ZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGQYD
VR0RBBIwEIEObWlsYW5AYmFzdGwuc2swDQYJKoZIhvcNAQELBQADggEBAAmdwRb6hdaUrIm+
C28unhZeOFUNXznQBwozcRh4EAnpzo9/l/lhtgqYQyZGlaROwfZKRGiyqOqPj5yOy0Bf0YRJ
qFs0z+Kj3hkrVksKg2TMZs17MCzI8u59IOld0bg81DPUv3pjbmSdrlSVvhKyxky3wrC9crZ/
YAroyQWp5lvL/jhpm0ra8TYm6QPv0ZVxSlayTRNfCGuc7BaUXLgGQhBuF0B0awPGA/Jh6YJ5
qXyVExw6VePHYrYZayn3lupYFzPj8SzA5zUtGsWc/AmACc/V2wObRQTbZoyKyVzHvxRE/5tw