[OT]C CO tim chtel basnik rici?

[Stano]

Vysledok bol 0xFFFFFFFF aj ked sa rotovalo 0xFFFFFFFFU a pocet bitov bol 
v premenej
Ak bol pocet bitov konstanta, vysledok bol vzdy nula.

A co sa normy tyka nasiel som len toto:

The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has 
an unsigned type
or if E1 has a signed type and a nonnegative value, the value of the 
result is the integral
part of the quotient of E1 /2E2.If E1 has a signed type and a negative 
value, the
resulting value is implementation-defined.

Rotacia signed nieje difinovana, ok, beriem, ale problem nastaval resp 
bol obiaveny na rotacii uint32_t premennej.
Len vramci ziednodusenia som ju nahradil konstantou (ano to explicitne 
pretypovanie tam chyba)
Kazdopadne aj s konstantou ci uz unsigned alebo signed alebo s premennou 
sa to spravalo rovnao.
Dokonca aj pre (usint64_t)0xFFFFFFFF << addr_rem bol vysledok stale 
rovny 0xFFFFFFFF a toto je uz myslim naozaj porusenie normy.



Jaroslav Buchta wrote / napísal(a):
> Jestli nebude na vine nejaka option prekladace, ze se provadi 
> implicitne posun aritmeeticky nebo logicky...
> Ten muj pokus dal 0 v obou pripadech a int je 32b - cili evidentne 
> provadi posun logicky.
> Kazdopadne tyhle chytaky asi zaslouzi v C-cku nebyt liny napsat 
> 0xFFFFFFFFU a je to jasne.
>
> Dne 31. 12. 2014 v 19:07 František Burian napsal(a):
>> "přičemž se doplňuje nulami" je právě ta chyba. Pokud 0xFFFFFFFF je 
>> int pak je signed a posunuje se znamenko takže by měl být výsledek 
>> -1. pokud bude uint měl by být 0 v obou případech.
>>
>> ---------- Původní zpráva ----------
>> Od: Pavel Hudeček <edizon na seznam.cz>
>> Komu: HW-news <hw-list na list.hw.cz>
>> Datum: 31. 12. 2014 18:45:59
>> Předmět: Re: [OT]C CO tim chtel basnik rici?
>>
>>
>>     To je nějaký divný. Zadání je jasné:
>>
>>     Vzít 32b int plný jedniček a 32x posunout, přičemž se doplňuje
>>     nulami.
>>
>>     - Proč by se to mělo přeložit jinak, než pro posun o 1, 2, 17,
>>     nebo třeba 35 bitů?
>>     - Proč by mělo (není-li chyba v překladači) vycházet něco jiného
>>     než 0?
>>
>>     PH
>>
>>     Od: Jan Waclawek
>>     To zavisi od velkosti int. Ak je viac ako 32 bitov, oba pripady
>>     su ekvivalentne, ak menej alebo rovne, obidva su nedefinovane,
>>     takze prekladac ma plne pravo vygenerovat lubovolny kod, ktory
>>     moze trebars aj spadnut. Rad by som, ale nemam teraz moznost
>>     citovat z normy.
>>
>>     Akurat ze gcc sa bude v prvom pripade snazit vygenerovat nejaky
>>     kod, co moze dopadnut vselijako v zavoslosti od konkretneho
>>     procesora; v druhom tam asi da v ramci jednoduchosti asi
>>     0xFFFFFFFF, t.j. akoby shift ani nenastal; ale moze to byt
>>     lubovolne inak.
>>
>>     >>>
>>     Na C alebo skor gcc mam tazke srdce koli inym "vlastnostiam"
>>     Len tak schvalne aky vysledok bude podla vas v tychto prikladoch:
>>
>>     uint32_t addr_rem, mask;
>>     addr_rem = 32;
>>     mask = 0xFFFFFFFF >> addr_rem;
>>
>>     A aky v pripade:
>>
>>     mask = 0xFFFFFFFF >> 32;
>>     _______________________________________________
>>     HW-list mailing list - sponsored by www.HW.cz
>>     Hw-list na list.hw.cz
>>     http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>>     
>
>
>
> ------------------------------------------------------------------------
> <http://www.avast.com/> 	
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <http://www.avast.com/>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>