C: char -> int

[Jan Waclawek]

Ja som si to pamatal lebo nedavno som to v ramci debaty na avrfreaks skumal:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=694015#694015

Derek Jones je clenom komisie s kuzelnym nazvom ISO/IEC JTC1/SC22/WG14, ktora pripravuje normy pre C; takze je mozne, ze sa nejaka zmena v tomto duchu v buducnosti v C1X objavi, ale v sucasnom zneni C1X (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1425.pdf ) tam ziadna takato zmena nie je.

wek


>ma ucel treba setreni mista. Mam-li vice udaju, ze kterych muze byt v
>jednom okamziku platny pouze jeden, tak je zbytecne zabirat misto pro
>ty ostatni datova pole.
>Marek
>
>2010/5/12 Ondrej <leguanolog at seznam.cz>:
>> add 3 - tak jak=FD m=E1 pak ta unie smysl, kdy=BE zm=ECna jednoho prvku m=
>=F9=BEe p=F8epsat
>> ostatn=ED?
>>
>> Dne 12.5.2010 12:22, Jan Waclawek napsal(a):
>>>
>>> Napriek tomu, ze sa to casto robi a aj ja to tak robim, union{ int a; ch=
>ar
>>> b[sizeof(a)]} ani union{ int a; struct {char b0, b1, b2, b3;}} na konver=
>ziu
>>> typov nedoporucujem, lebo:
>>>
>>> 1. prvky pola ako aj prvky structu mozu byt zarovnane ako kompilator chc=
>e,
>>> t.j. nemusia lezat v za sebou nasledujucich byte
>>> 2. endianita viacbytoveho typu je ako kompilator chce
>>> 3. podla normy, po zapise do jedneho prvku unionu maju ostatne prvky
>>> nedefinovany obsah (6.2.6.1#7)
>>>
>>> Aj ked sa obvykle ako problem cituje 2. (ktory sa da obist sadou makier
>>> pre rozne endianity) a obcas 1 (na ktore zase ma napr. gcc nestandardny
>>> atribut __packed__), podla mna je najzakernejsi problem 3 (ktory je pome=
>rne
>>> neznamy, a moze sa prejavit napr. ako nasledok optimalizacie).