gcc-11.2

Épp most fordult, kíváncsian várom, milyen új hibaüzenetekkel örvendeztet meg. (Ez nem valamiféle tréfa, szó szerint értem: esetemben az upgrade legfőbb/egyetlen célja az, hogy minél több (potenciális) hibát találjon meg a compiler.)

Kezdetnek észrevette, hogy ez a kettő illene egyforma legyen:

extern void Translay (const unsigned char *table, size_t len, void *add);
void Translay (const unsigned char map[256], size_t n, void *buff)

( uid_6201 v | 2022. 03. 22., k – 08:08 )

Szerkesztve: 2022. 03. 22., k – 08:28

Neked is megvan a perverziód, mint a gcc fordítása.
Nekem utoljára kb. 10 éve ARM mikrovezérlőhöz kellett crosscompilert fordítanom, de ma már a disztró része, így nem forgatom.

$ apt-cache search gcc-arm-none-eabi
gcc-arm-none-eabi - GCC cross compiler for ARM Cortex-R/M processors
...

Bár újonnan az ARM mikrovezérlők terén is részben eltolódtam a Rust felé, az is kb. a gcc palettáját támogatja:

$ rustup target list | grep none-eabi
...
thumbv6m-none-eabi
thumbv7em-none-eabi
thumbv7em-none-eabihf (installed)
thumbv7m-none-eabi (installed)

Egyúttal az a perverzióm, hogy versenyeztetem a két nyelvet és lehetőségeit.

Egyébként tény hogy szigorúbb lett a C fordító. Több projekt új GCC-vel való fordításakor kell helyére reszelnem nekem is egy-egy headerbeli és implementációbeli eltérést, amit néha nem is értek, hogy addig hogyan csúszhatott át. Továbbá sokkal több trehányságot felfedez és tolja a figyelmeztetést. Nagyon sokat fejlődött a GCC az elmúlt 5..6 év során is, pedig már 35 éve létezik.

Mi abban a perverzió? Én is forgattam magamnak ide újabb GCC-t (6-os helyett 7-est), meg amigás fordításokhoz cross-compiler GCC-t.
Miért versenyezteted a C-t a Rusttal? Nem baj, hogy nem ugyanabban a ligában játszanak, hogy egy magas szintű nyelvet versenyeztetsz egy hordozható assemblyvel? C++ vs. Rustnak még volna is értelme, ennek semmi, hacsak nem a C-haterkedés, mert persze sose sebességet, kódméretet, vagy hordozhatóságot nézzük ezeken a "megmérettetéseken"...

Oldschool Computer - http://oscomp.hu

Miért versenyezteted a C-t a Rusttal?

Oka egyszerű:

  • Alaposan megismerni a lehetőségeit.
  • Alaposan megismerni a korlátait.
  • Ezáltal el tudom dönteni, hogy az adott alacsony szintű feladatnak melyik nyelvvel praktikus nekifutnom.

Tapasztalatom, hogy sok feladatra célszerűbb a Rust, viszont akad, amire valójában a C jobb választás.

Nem baj, hogy nem ugyanabban a ligában játszanak,

Ennek ellenére pontosan ugyanazt a feladathalmazt, amit eddig kizárólag C-ben írtam, azt tudom vele kiváltani kényelmesebben, biztonságosabban, karbantarthatóbban.

Amennyiben a hordozhatóság nem szempont, ill. a Rust overheadje a céleszköz számára elhanyagolható, akkor te nyilván jobban jársz a Rust-tal, csak ebben az esetben meg azért nincs értelme versenyeztetni, mert no-contest, amiben jobb a C, az neked nem számít.
Ami a lehetőségeket és korlátokat illeti, más embernek más számít lehetőségnek és más korlátnak. Te nyilván korlátnak látod, hogy a C nem reklamál be bizonyos dolgok miatt, én viszont lehetőségnek, hogy megtehetem őket. Nem kéne? Lehet, de ez az én hibám, nem a nyelvé. Ugyanez pepitában: neked lehetőség, hogy a Rust egy hello world-re is bereklamál, hogy nem biztonságos módon írattad ki a sztringet, nekem viszont ez korlátozás. A szemszög rengeteget számít. Így viszont megint nincs értelme versenyeztetni őket, mert szubjektív lesz a győztes, azt meg verseny nélkül is ki lehet jelölni. Neked kb. csak akkor van értelme C-hez nyúlni, ha a Rust annyival lassabb kódot eredményezett, hogy az már impactnak számít, vagy, ha a Rust nem érhető el a platformon, ahova épp fejlesztesz; minden egyéb esetben jobban jársz a Rust-tal.

Viszont kár azért kárhoztatni a C-t, hogy nem tudja azt, amit nem is kell neki tudnia, hogy nincs benne olyasmi, aminek nem is kéne benne lennie.

Oldschool Computer - http://oscomp.hu

Akkor forgasd le most, meglátod milyen hosszú idő, még egy combosabb gépen is. Jó, annyira nem durva, mint Chrome-ot, Firefoxot vagy SageMath-t forgatni, de nem is épp röpke. Általában felesleges is, mert a disztrók tárolójában benne van, vagy külső tárolókban, PPA-kban van újabb verzió, ha a disztró nem tudna szállítani, csak régit. Plusz csak azért fordítani, mert hátha kiír valami ajánlást. Különben is, ha új kell, akkor most jelent meg a 14-es LLVM/Clang, ami modernebb fordító, újabb szabványokat is ismer, amik egyébként bekerülnek a nemsokára megjelenő gcc 12-be is.

Esetleg ha csak tényleg nézegetni kell, akkor gyorsabb lehet egy VM-be egy friss rolling disztró, ami már tartalmazza a 11.2-es gcc-t, esetleg a 14-es Clangot.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( NevemTeve | 2022. 03. 22., k – 08:19 )

Ilyet is fogott:

somecode.c: In function 'CHK_JOGE2_r':
somecode.c:205:9: error: 'J3_CheckUserJognev_r' reading 32 bytes from a region of size 6 [-Werror=stringop-overread]
  205 |     rc= J3_CheckUserJognev_r (j3v, userid, myszerep);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
somecode.c:205:9: note: referencing argument 3 of type 'const char *'
In file included from somecode.c:10:
jog3way.h:197:5: note: in a call to function 'J3_CheckUserJognev_r'
  197 | int J3_CheckUserJognev_r (Jog3Var *j3v, const char userid[12], const char jognev[32]);
      |     ^~~~~~~~~~~~~~~~~~~~

( uid_6201 v | 2022. 03. 22., k – 12:04 )

Egyre kritikisabb szemmel nézek még a C-re. Egy példa, amiért sajnos még nem rinyál nálam a C fordító:

#include <stdio.h>
#include <string.h>

char *checkuser(char user[12]) {
    return &user[12];
}

int main() {
    struct _user {
       char name[12];
       char passwd[30];
    } user;

    strcpy(user.name, "ElsoUser");
    strcpy(user.passwd, "TitkosJelszo");

    printf("User?: %s\n", checkuser(user.name));
    return 0;
}

Ezt a szivárgást nem tudod elérni Rust esetén. Nem enged ki sem olvasásra, sem írásra a cimke számára lefoglalt memóriaterületről.

Ebben mi a baj? Keresed a '\0'-t, miközben túlcímzel a tömbödön. Az ellen sem véd semmi, ha egy random számot írsz egy pointerbe, majd azzal összefirkálod a memóriát. Szerintem a programozónak is van hülyeséghez való joga, nem csak egy random polgárnak. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( NevemTeve | 2022. 03. 22., k – 13:31 )

Szerkesztve: 2022. 03. 22., k – 13:45

Most meg is akadtam...


void fun(SomeStruct *p[3]) {...}

fun2() {
    SomeStruct p[12];
    fun(&p[7]);
}

Azt mondja,hogy ez nem jó, 24 byte-nyi terület kellene a hívottnak, nem 8. Ez mit sem segít: fun((SomeStruct **)&p[7])

Hát igen, jól le akartam egyszerűsíteni a problémát, közben sikeresen elrontottam. A lényeg, hogy éberebb lett a fordító a SomeType arrptr[3] szerű függvényparaméterekkel kapcsolatban, a gond az volt, hogy nekem történelmileg ilyen struktúrám van:


typedef struct Egybe {
    SomeType reggeli;
    SomeType ebed;
    SomeType vacsora;
} Egybe;
Egybe e;

Na ilyenkor a &e->reggeli sehogy sem lesz jó ilyen függvényparaméterként. Vagy legalábbis nem találtam olyan typecast-ot, amivel ne jött volna warning.

( NevemTeve | 2022. 03. 22., k – 13:44 )

Szerkesztve: 2022. 03. 22., k – 13:45

Egy kis bónusz:

Reading symbols from /home/projects/phptest/guest/c/arrptr2...
Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4)
[in module /home/projects/phptest/guest/c/arrptr2]
(no debugging symbols found)...done.

( NevemTeve | 2022. 05. 19., cs – 10:04 )

Valamint valgrind. Mondjuk ott van még egy segítő játékos, úgy hívják, hogy Oracle-kliens:


==40129== Use of uninitialised value of size 8
==40129==    at 0x99E8EDA: r0_des_encp_k8_64 (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x99BE958: r0_cipher_cbc8lup_enc (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x99BEC3B: r0_cipher_cbc8lup (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x99BEC7A: R1_CIPH_CTX_cipher (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x99A9B89: r_ck_cipher_update (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x98A1DFB: ztca_RSAAdpEncrypt (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x9AE1FA4: ztcebn (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x9AE10C8: ztcecrypto_2 (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x9889E0B: ztceenc (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x98A3914: ztcrbm (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x98A338F: ztcrbh (in /opt/instantclient_12_2/libnnz12.so)
==40129==    by 0x98A3136: ztcrbp (in /opt/instantclient_12_2/libnnz12.so)
==40129==.
==40129==.
==40129== More than 1000 different errors detected.  I'm not reporting any more.
==40129== Final error counts will be inaccurate.  Go fix your program!
==40129== Rerun with --error-limit=no to disable this cutoff.  Note
==40129== that errors may occur in your program without prior warning from
==40129== Valgrind, because errors are no longer being displayed.

( NevemTeve | 2022. 08. 29., h – 12:45 )

A gcc-11.3 is lefordult, kevesebb mint négy óra alatt (3:47:11). Meglátjuk, van-e valami változás, elméletileg főleg csak javítások vannak benne.

Még fordítgatsz egy pár órán át, és be fogod látni, hogy erre vannak kitalálva a rolling disztrók, pl. Arch, Void, Fedora (jó, az csak félrolling), stb..

Archon pl. kapásból default a 12.2.0-ás gcc, és simán bináris csomagból a 14.0.6-os llvm/clang-ot is felteheted, a kemencéből kiemelve olyan frissek, hogy még gőzölögnek, a kódot akármelyikkel átnézheted. Mindjárt használhatod, nem kell semmit fordítgatni órákon át. A másik véglet, a Gentoo, ott mindent fordítgatsz, de azt se kell kézzel csinálnod, az emerge megoldja automatice, bár olyan gépre szerintem nem ajánlott, ami majdnem 4 órán át fordítja a gcc-t, mert tökön szúród magad kínodban, ezek akkor jók, ha valami combosabb i7-i9, Ryzen 5-9, Threadripper, Xeon procid van több maggal, komoly cache-el, tisztességes méretű RAM-mal (16 giga ebben a műfajban csak nagyon a minimumot karcolja, 32-64 között ajánlott), azok lenyomnak egy gcc-t méretű fordítást fél-egy óra között, az se olyan sebes, hogy a hajad lobog bele, de kivárhatóbb szint.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”