[Játék] Találd meg a bug-ot!

printf("Element: %x\n", *element);
 

Így lenne jó: 
if (element != nullptr) {
    printf("Element: %x\n", *element);
} else {
    printf("Congratulations, you've found the borked index!\n");
}

Ez tele van bugokkal, de a legnagyobb rohadt nagy bug, hogy mi a francért keveri a C++ kódot a C-vel??

C++-ban FILE típus? C++-ban C típusú tömb, std::vector helyett? printf meg stream-ek keverése...

Pont az ilyen gyökér keveredések miatt annyira népszerűtlen a C++.

Ezen kívül:

* nincs ellenőrizve a fájl megnyitása,

* nincs ellenőrizve a fread által olvasott elemek száma. Meg amúgy is szebb is lenne sizeof(uint32) és count=SIZE2-vel meghívni.

* nullptr-t nem kellene átadni a printf-nek. Amúgy is mi a tököm miatt ad át címként egy uint32-t (már ha nem akar beleírni).

félig laikusként a sizeof jól kezeli ezt unsigned int32 -t?

#include <stdio.h>
#include <iostream>

Ennél tovább nem szükséges olvasni, a kód úgy, ahogy van, a kukába való.

if (index >= (SIZE + SIZE2))...

8,9... től jön a secret

...ja, hogy nem a secret a goal, hanem a bug :) 

akkor if (index >= SIZE || index < 0) bár unsigned miatt mind1... passz

A kiírás hibás.

A main függvény lokális vermébe kerül X címre az arr, majd X - 32 címre a secret, így nyilván arról van szó, hogy a get_element_safe() függvényben kell túlcsordulást előidézni a "return arr + index" sorban, méghozzá az is biztos, hogy egy fordítóbug kihasználásával (a hiba nem szemantikai, hanem fordítóbeli).

Csakhogy, ennek megválaszolásához tudni kéne, hogy mennyi a sizeof(uintptr_t), azaz hogy 16, 32 vagy 64 bitesre fordítunk-e. Ennek ismerete nélkül nem is adható helyes válasz, tehát hibás - konrétan hiányos - a feladat kiírása.
ps: Ezen kívül a printf valóban UD-t eredményez bármilyen index >= 8 bemeneti értékre, és valóban eleve balfasz, aki így keveri a C-t és C++-t, de pláne a FILE-t a streamekkel. Gyanítom, ez triggereli a fordítóbugot az inlineolás kódgeneráló részében; és stream helyett fgets+atoi és sima C fordítóval valószínűleg eleve nem is jönne elő.

De mégegyszer, ez nem szemantikai, hanem fordítóbeli bug, tehát ismerni kéne a pontos fordítót, a célarchitektúrát, a címbusz méretét, de mivel inline-ról van szó, még a fordítónak átadott optimalizációs kapcsolók sem mindegyek!

clang és az inlineolt boundscheck esete

Ha jól látom csak a számsorral feltöltött arr-ból olvas a megadott indexnél nem pedig a secret-ből amit ki kéne "csorgasson". A printf feletti sor.

(A SIZE2-vel kéne ellenőrizni az indexet, de mivel ugyanannyi mindkettő, most mindegy.

Szerencsétlen, hogy ugyanaz a neve a függvényparaméternek meg az egyik tömbnek.

nullptr nekem új, de c++-os dolog szóval nem kéne, meg nem kéne keverni a dolgokat. )

Azert ez aljas... vagy hat, nem is tudom mit lehet erre mondani. 

Ez de beteg egy bug. :)

A nullpointer hibát én is kiszúrtam, de úgy voltam vele, hogy ezzel túlcímzést megvalósítani ponthogy nem lehet. A fileműveletek hibakezelés-hiányát detto.

Az a nyomorult inline... sejthettem volna, hogy az okkal van ott. Az a bizonyos puska, ami ha kinn van színpadon, biztos lehetsz benne, hogy a színdarab végéig el is fog sülni. :)

Én ugyan nem, de a clude tudja a választ.
Bemásoltam neki a képet, azzal, hogy old meg a feladványt. Szépen levezette.

Na jó, de mit kell neki beírni, hogy listázza a secret-et?

$ clang++  sec.cpp
]$ ./a.out
8
Segmentation fault (core dumped)
 

És itt:

clang++ -O2 sec.cpp
./a.out
8
Element: 64636261

(secret.txt: abcdefgh)

GCC-vel:

$ g++ sec.cpp  
$ ./a.out  
8
Segmentation fault (core dumped)
 

$ g++ -O2 sec.cpp  
$ ./a.out  
8
Segmentation fault (core dumped)

Szép! Érdekes és tanulságos, köszönjük, hogy kitetted!

Mindig is mondtam, hogy az undefined behaviour-t tűzzel és vassal kell irtani. Ami optimalizációnak ez az alapja azt eleve nem kellene csinálni, mert valójában hibát csinál, nem optimalizál. (Várok olyan példát, aminek értelme is van, és nem lehetne UD nélkül megcsinálni.) A szoftverfejlesztő agyérgörcsöt kap az ilyenektől. A C fordító fejlesztő meg "smugface"-t nyom, hogy de hát tök gyors lett a kód, talán nem? És megfelel a specifikációnak, talán nem?

Nem csodálkoznék, ha kiderülne, hogy ürgebőrbe varrt szovjet ügynökök tették az UD-ket a C specifikációba!