Kb. arrol van szo, hogy az ABI eloirja (hogy miota azt nem tudom, de nem olyan reg ota mint ahogy az FPC C ABI kezelese keszult... :D) h. ha egy C-s bool-t adsz at, akkor csak a legalso bitje szamit, az lesz 1 v. 0. Ez nem tul ujdonsag, es a C99 ota a nyelv specifikacio resze is, szoval kb. lecopypasteltek a Pascal booleant (ami dokumentaltan 0 v. 1 ha ordinalt kersz belole, osidok ota).
Csak eppen mindenki azt hiszi, hogy a C-ben a true az barmi lehet ami nem 0, a false meg mindig 0. Na ez nem igaz mar. :) A Free Pascal is azt hitte, ezert a C boolean kezeles -1-t (0xff) forditott oda "true"-kent, ahol a C kod szigoruan 1-t vart. A C kod meg valahogy igy nezett ki:
void foo(bool bar) {
char flags = (bar & 0x1) << 1;
send_buf(flags);
}
A halozati packetben viszont mi jelent meg flags-kent? 0xfe (254). Mert ugye, a GCC okos, es rajott h. hat a bar valtozo egy bool, ahol az ABI eloirja h. csak 0 v. 1 lehet, ergo optimalizaljuk szepen ki a kodbol a 0x1-vel valo andolast hiszen nem kell az oda! :D
Igy lett az h. 0xff << 1 -> 0xfe :) Bonusz, hogyha igy hivod meg a C kododbol a fuggveny h: foo(-1); akkor a GCC mindenfele warning vagy barmi nelkul atirja a leforditott kodban a hivo oldalon a -1-t 1-re... :)
Ami azert kell, mert a C kodban (ellentetben a pascallal) ugyan most mar a booleanok 0 v. 1-re vannak eloirva, de attol meg az int vs. bool atjarhatosagot a regi kodokkal valo kompatibilitas miatt biztositani kell, ezert van az h. a fordito azt hiszi, hogy majd o csendben megoldja ezt neked, te azt hiszed minden rendben, aztan az arcodba esnek ilyen szepsegek...
Azota a Free Pascal is tudja, hogy a cbool <> barmi ami nem 0, hanem szigoruan 1. :)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-