zakerna zahada GCC

Josef Štengl ok1ced na nagano.cz
Středa Únor 7 23:01:07 CET 2018


sizeof je vyhodnocována v době překladu ... většinou. Ale to je zde jedno kdy, pole je statické a je známa jeho velikost.

Jestli to chápu správně, druhou podmínku kompilátor oprávněně vypustí, protože nemůže (teoreticky) nastat.

Soudím dle
6.5.2.1#2):

If the result points one past the last element of the array object, it
shall not be used as the operand of a unary * operator that is evaluated.

Tudíž druhá část podmínky je nadbytečná, protože protože vyhodnocuje stav, kdy je index mimo rozsah pole a tudíž předchozí 
podmínka v && nemá právo na vyhodnocení a tudíž by tato situace teoreticky neměla nastat. Tedy v této kombinaci. obráceně 
je to jiná situace.

Kdyby pole bylo dynamicky alokováno, tak by se ta podmínka podle mě měla vždy vyhodnotit. I když by se samozřejmě 
neporovnávalo se sizeof toho pole.

Autoři na GCC jsou při optimalizacích poměrně agesivní, co se týče specifikace (jdou až kam jim to norma umožňuje a 
nezajímá je, jak si to pisatel vysvětluje). Tohle posle mě není bug.

Hmm. Vážně to nepíše žádné varování? Já se snažím nastavit překladač na pavlačovou babu (maximální množství komentářů ze 
stany kompilátoru). A málokdy zaznamenám nepřínosnou hlášku. Ono stejně je překladač oproti misra hláškám je to jen takový 
slabý čajíček.

Mě dostala jiná věc. V přerušení vyhodnocuji jednoduchou podmínku (testuji v ifu hodnotu proměnné), kterou nastavuji po 
inicializaci - to přerušení se rozběhne dříve (musí). Co jsem nečekal, bylo to, že se podmínka v přerušení sice 
vyhodnocovala, ale hodnota zapisovaná po rozběhu přerušení se nezapisovala (zapisovalo se do té proměnné jednou a 
inicializace byla statická na nulu při deklaraci proměnné). Prostě to kompilátor vyhodil z kódu změnu hodnoty, ale 
testoval ji.  Po volatile to fungovalo, ale  dost mě to překvapilo. Možná neoprávněně, nevím.
Pravda, byla to nejagresivnější optimalizace na rychlost a o stupeň méně to už nedělal (byl to armcl překladač od TI).


On 7.2.2018 22:02, Petr Simek wrote:
> On Wed, 7 Feb 2018, Jindroush wrote:
> 
>> char  text[19];
>> char text2[19];
>>
>> int main()
>> {
>>   for( size_t idx = 0; text[idx]!=0 && idx < sizeof( text ); idx++)
>>   {
>>     text2[idx]=text[idx];
>>   }
>> }
>>
>> Opravdu tu druhou podminku eliminuje a uplne tomu vysvetleni nerozumim.
> 
> Neni to chybne definovana podminka ? Kdyz bude v ramci pole text nekde
> nula tak to zastavi ta prvni podminka, ta druha podminka naopak zpusobi
> ze pokud nebude pole text obsahovat nulu tak idx bude vetsi nez sizeof (text) takze ta druha cast podminky nikdy 
> nenastane. Bud se to sekne
> na nule v poli text nebo to pobezi az mimo pametovy segment.
> 
>> J.
> 
> *------------------------------------------------------------------------*
> |                          Petr Simek   APS JU                           |
> |                             psimek na jcu.cz                              |
> *------------------------------------------------------------------------*
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list


Další informace o konferenci Hw-list