HWSW lámer ámokfutás folytatódik... halál a C nyelvre!

Közösségi kerekasztal

Ráerősít a Google a memóriabiztos nyelvekre

"Ahol lehetséges, ott a keresőcég elszakad a C-től és a C++-tól, de az átállás nem fog egyik napról a másikra történni."

Na most attól még, hogy a cikkíró Dömös Zsuzsanna már sokadik cikkben tesz hitbizonyságot arról, hogy nemcsak egyszerűen nem tudja mi a különbség C és C++ között, de kimondottan büszke is erre, nem kellene saját dilettáns gondolataival kiegészítenie a becitált forrásokat, amiket láthatóan nem ért. Átolvasva a linkelt Google anyagot sehol nem láttam utalást a C nyelvre és annak szükségszerű lecserélésére. Ha elkerülte volna figyelmemet akkor ezúton kérek elnézést. 

  • 2935 megtekintés

( pink v | 2024. 03. 06., sze – 16:21 )

Azért arra lehet számítani, hogy a C egyre jobban vissza fog szorulni (mint ahogy szorult vissza az elmúlt évtizedben is).
Nyilván kihalni nem fog, de lesz, ahol átveszi a szerepét más. Ennek több oka is van, köztük a nyelvi kérdésen kívüliek is - pl. a trendek, változó igények.

Azért arra lehet számítani, hogy a C egyre jobban vissza fog szorulni (mint ahogy szorult vissza az elmúlt évtizedben is).

Ezen állításodat tudod bizonyítani? Merthogy a github statisztikák pl. nagyon nem azt mutatják, amit állítasz...

Mindig lehet találni olyan merítést, amire valami vagy annak az ellenkezője lesz igaz.
A github nem a világ.

Magam egyébként (low level) C / C++ programozó vagyok (bár egy ideje már nem ebből élek).
Szomorúsággal tölt el látni a hanyatlásukat. Ugyanakkor dőreség volna erről nem tudomást venni.

Szerintem nem arról van szó, hogy lettek ,,jobb" nyelvek és eszközök. A célok, a környezet és a szempontok változtak meg az évek során.

A mi életünkben szerintem még mindig meglesz ezeknek a nyelveknek a helye, rengeteg munka van a csiszolgatásukban, a fordítókban és a toolchain-ekben is. De ezek a területek egyre inkább speciálisak, mintsem a mainstream.

Érdekes az általad linkelt github statisztika, ám meg kell jegyezni, hogy a benne szereplő nyelvek számos esetben nem alternatívái egymásnak.
Kíváncsi lennék még pl. a Go fantasztikus térnyerésének hátterére: vajon ezek valódi projektek, vagy inkább edukációs jellegűek?
Látni, hogy a Rust lassan, de biztosan jön felfelé. Számomra a Rust az a nyelv, amiben esélyét látom a C / C++ sikeres reinkarnálódásának. Tudom, hogy ez nem lesz ugyanaz, de hát a világ sem ugyanaz már.

A github nem a világ.

Nem, csak épp a legnagyobb kódmegosztó a világon. Ha hozzávesszük a többit is, mint pl. sourceforge, gitlab stb., akkor még szembetűnőbb lenne, hogy nem megy a C sehova. És korántsem arról van szó, hogy sok meglévő projekt miatt nem bír kihalni.

Figyeld csak meg, évről évre újabb és újabb projektek indulnak benne! Például a Facebook zstd-je, vagy akár a Google webp-je, vagy a jxl. Ezek mind mind új (pár éves) projektek, amiknél fontos a minőség, hatékonyság és portolhatóság, és hype ide vagy oda, mégis C-ben álltak neki megírni őket és nem Go-ban vagy Rust-ban. Nem véletlenül!

Vagy vegyük akár a legfrissebb, most cutting edge post-quantuum titkosítási algoritmust. Mit gondolsz, milyen nyelven álltak neki megírni a PoC-ot hozzá?

A célok, a környezet és a szempontok változtak meg az évek során.

Valójában nem változtak sem a célok, sem a szempontok, csak a környezet lett ezerszer gyorsabb, így több hülyeséget elbír. Lásd Wirth törvénye.

De ezek a területek egyre inkább speciálisak, mintsem a mainstream.

A C sosem volt igazán mainstream (leszámítva talán az Amiga fénykorát). Tipikusan akkor esik rá a választás, amikor a marketing bullshittel meg a hangzatos szavakkal kitörölhetik; tényleges mérnöki értelemben vett minőségre, hatékonyságra meg portolhatóságra van szükség. Na az ilyen komoly projektek mind a mai napig C-ben indulnak (lásd fentebbi lista pl.).

Érdekes az általad linkelt github statisztika, ám meg kell jegyezni, hogy a benne szereplő nyelvek számos esetben nem alternatívái egymásnak.

Természetesen nem. Jól látszik, hogy a szkriptnyelvek szakítanak, mert ahhoz ért csak a mostani sok vérpistike. Azt meg kell jegyezni azonban, hogy ennek tükrében még előkelőbb a C és a C++ top 10-es helyezése.

Kíváncsi lennék még pl. a Go fantasztikus térnyerésének hátterére: vajon ezek valódi projektek, vagy inkább edukációs jellegűek?

Igen, ez nagyon jó kérdés, bennem is felmerült. Nem tartom kizártnak, hogy a sok Godot tutorialt másoló projekt szépíti a statisztikát.

Számomra a Rust az a nyelv, amiben esélyét látom a C / C++ sikeres reinkarnálódásának.

Nem mennék itt bele, mert máshol már kifejtettem bővebben, hogy ez miért ugyanolyan hülyeség, mint amikor a COBOL, C++, Java, Go stb. nyelvekről mondták ugyanezt. Azok sem váltották le a C-t, a Rust sem fogja.

(Azt, hogy a Rustban hemzsegő tervezési hibákat sosem lesznek képesek kijavítani, még maguk a Rust alkotói is beláthatták, mert a további pofozgatás helyett inkább egy új nyelv fejlesztésébe kezdtek. Csak szólok.)

Tudom, hogy ez nem lesz ugyanaz, de hát a világ sem ugyanaz már.

Hát éppen ez az! A világ nagyon nem ugyanaz már, mint 1989-ben, amikor az első C szabvány kijött, és mégis még mindig újabb és újabb projektek indulnak benne. Pont ezt mondom én is, a C örök :-)

Hát, ha vissza is szorul, max. azért, mert az egyre több, programozónak mondott ember nem tud benne programot írni, és muszáj valami magasabb szintű, félautomata nyelven dolgozniuk, hogy működőképes produktumot állítsanak elő a hülye sprinteken, ahol a minőség nem, csak a határidő számít.

A szoftver(fejlesztés) arra való, hogy pénzt termeljen. Hobbinak elég faszság, mert az ülés nagyon egészségtelen. Szóval igen, ha a félautomata nyelv több pénzt termel, akkor jobb.

Ráadásul biztonsági vonzata is van a dolognak. Lehet mondani, hogy egyszerűen jó kódereket kell alkalmazni, nem lesznek lukacsosak a programok, de ennyire nem egyszerű:

  • Azoknak a jó kódereknek a hozzáállása is meg kell legyen, nem lehetnek hanyagok.
  • Lehetőleg rossz napjuk se legyen.
  • A motivációjuk se csökkenjen.
  • És mindemellett pénzt is termeljenek.

Melyik szervezet tudja ezeket tartósan és ellenőrizhetően biztosítani? Szerintem egyik sem. Így a biztonsági kihívásokra a válasz – amellett, hogy nyilván próbálod résztvevők technikai szakértelmét maximalizálni – az eszközök felülvizsgálata, lecserélése is.

Bortontoltelekekkel kene programot iratni, elvegre ok mar egyebkent is ulnek. Programhiba eseten git blame szerinti "fejleszto" plusz egy ev. Ha a hiba CVE szamot kapott, akkor instant kivegzes amit kozvetit a borton TV, motivacios eszkozkent. Tovabbi motivacio, hogy az altaluk termelt penzbol vasarol a borton kajat a raboknak. Ha nem termelnek, akkor eheznek. Internet nincs, de van helyi mirror a stackoverflow meg meg nehany szakmai site tartalmarol. Plusz szakkonyveket rendelhetnek, de csak azert, mert a szomszed forumban eppen azokrol volt szo. :-)

Értem amit írsz, magam sem gondolom másképp. Egy ideális világban. Ráadásul nem dolgozok szoftver fejlesztésben, hanem üzemeltetésben, de emiatt van valamennyi rálátásom a produktumokra.

Ha így van a fejlesztő iparban amit írsz, ahogy írod, akkor miért van az, hogy a sok, munkát nagyban segítő, a hibák nagy részét kizáró, sok dolgot automatizáló nyelv mellett több a szar program (arányaiban), mint amennyi volt akkor, amikor ezek a nyelvek, rendszerek nem léteztek és jó programozók C-ben meg C++-ban tudtak csak fejleszteni?

Egy jobb fejlesztő rendszer egy jó programozón segít. A rossz programozót meg esetleg kihúzza a csávák egy részéből. Sajnos utóbbiak vannak többségében, és amiből a fejlesztő eszközök nem húzzák ki őket, annak isszuk a levét nap mint nap. Pl. Windows-nál mikor volt utoljára olyan patch kedd, amikor nem borult meg valami látványosan, sokaknál? Hát, inkább csak kéthavonta lenne, csak ne kellene újraírni a felét kiadás után...

Az a baj, hogy olyan ez is, mint az autókban az ESP. Azért van, hogy ha valami váratlan történik, akkor korrigáljon. De ezt sokan úgy értették, hogy ha határon autóznak, akkor majd az ESP megmenti őket a fizikától. Ugyan ez igaz az IT-re is. A jó eszközök a hozzáértőknek segítenének, de valójában a hozzá nem értők hiszik magukat tőlük jobbnak, mert az eszköz megoldja a dolgok egy részét, amit ők maguktól nem tudnának.

A régi (15-20 évvel ezelőtt írt) átlag kód ugyanolyan, ha nem rosszabb minőségű volt, mint a mostaniak, csak jóval alacsonyabb implementációs szintre lőttek.

Ez nagyon nem igaz.

Pont, hogy SOKKAL magasabbak voltak az implementációs elvárások, mert meg kellett küzdeni még az akkori platformok megszorításaival is. Mégsem emlékszem, hogy anno az MS-DOS-os programok bugosak lettek volna, vagy lefagytak volna...

Konkrét példa: Elite II Frontier, nem kis kihívás 457K-ba leprogramozni több naprendszernyi 3D-s világot, bolygókkal, holdakkal, űrállomásokkal, űrhajókkal, kereskedelemmel, tokkal-vonóval stb; mindezt úgy, hogy a processzor egyszerre csak 64K-t képes címezni, és sehol egyetlen egy bug sem, na erre egyetlen mai programozó sem lenne képes.

Kb. a 90-es évek végétől kódoltam, assembly, pascal, C nyelven. Hidd el, azok a kódok a mai szemmel nézve "megoldottak" dolgokat, de nagyon sok tákolás/"okos megoldás" volt bennük, nem véletlenül inkább teljes újraírással cserélték le azokat a rendszereket, mert teljesen karbantarthatatlanok voltak. Tesztekről meg nem is hallott senki, egyszerűen nem voltak teszt keretrendszerek.

Nem véletlenül vannak most már coding convention-ök, automatikus build rendszerek, unit tesztek, normális verzió követés, code review, stb. Egy normálisan fejlesztett kód messze jobb minőségű, messze jobban karbantartható, és nagyságrenddel komplexebb, mint a régiek voltak. 

"Nem véletlenül vannak most már coding convention-ök, automatikus build rendszerek, unit tesztek, normális verzió követés, code review, stb. Egy normálisan fejlesztett kód messze jobb minőségű, messze jobban karbantartható, és nagyságrenddel komplexebb, mint a régiek voltak. "

 

ezekre mind azert lett igeny, mert nagyon felhigult a szakma :D

HUP te Zsiga !

A régi (15-20 évvel ezelőtt írt) átlag kód ugyanolyan, ha nem rosszabb minőségű volt, mint a mostaniak

Kb. a 90-es évek végétől kódoltam, assembly, pascal, C nyelven. Hidd el, azok a kódok a mai szemmel nézve "megoldottak" dolgokat, de nagyon sok tákolás/"okos megoldás" volt bennük

Ezt készséggel elhiszem, mint ahogy azt is elhiszem, hogy a mostani kódjaid ugyanolyan rossz minőségűek, mint a régi kódjaid.
De ez még nem ok az általánosításra, mint ahogy Te tetted.

Láttam az akkor irt kódokat, látom a mostani kódokat, látom hogy mennyit fejlődött a szakma minden téren. Láttam komplett projekteket kukában landolni, mert ember nem volt aki átlátta volna. De persze értem, hogy aki csak 2000 soros embedded kódokat írt egy IC-re egész életében, az le is ragadt azon a szinten. De hát nincs ezzel gond, a kutya ugat, a karaván halad. 

Pont, hogy nem. Akkoriban dobozos termeket gyartottak, a floppyra, CD-re sokezer peldanyban kiirt program utolagos modositasa es eljuttatasa a felhasznalokhoz iszonyat draga volt, ezert a managerek szamara is fontosabb volt a minoseg, mint az elkeszulesi ido.

Ma divat a konkretan felkesz szoftvert atadni a felhasznalonak, hogy tesztelje elesben, lasd Windows.

A Windows 3.11 felhasznalasi mintaja megegyezik a Windows 11 -el, megis ez utobbit folyamatosan takolni kell, mert nincs kesz. A 3.11 -re ki tudtak jelenteni, hogy kesz, kiadhato. A Win 11 viszont akkora egy bloat, hogy esely sincs rendberakni, es azt mindani ra, hogy keszen van, mar csak az uj vasakkal megjeleno drivereket fogjuk frissiteni.

Ugyanez Office es minden mas programcsomagra is ervenyes. 

Éppenséggel fájlkezelő volt benne, hálózati meghajtót is fel tudott csatolni.

Volt benne chat, telnet, ftp kliens.

Volt rá böngésző, PDF olvasó, email kliens, szövegszerkesztő, táblázatkezelő, grafikai program is.

Szerk: és persze mp3, videólejátszó is.

az os telepítés és havi frissítés végén pedig olyan a win, mint a főutcán végigmenni. Van egy kis aprója? Szórólapot? Vegyen bizsut, játékot. Adakozás? Előfizetés? Meghatalmazás pénzlevonásra? Megmutatod az andoid telódat?

Úgy érzem magam, mint idiana jones. https://www.youtube.com/watch?v=kQKrmDLvijo

A felhasznalasi minta volt ugyanaz, nem maga a szoftver.

Hasznaltak jatekra es irodai programok futtatasara egyarant. Hasznaltak termelesben es oktatasban egyarant. Szerkesztettek es tordeltek rajta szoveget. Adatbazist kezeltek rajta, Excelben tablazatokat kezeltek, pont ugx ahigy ma is teszik az emberek. Nekem remlik, hogy ment rajta a Netscape Navigator, szoval meg internet is volt. Kepnezegeto is volt, mert es pornokepek is voltak, csak akkor meg floppyn utaztak a csajok. Cegek hasznaltak, maganemberek hasznaltak, pontosan azokra a celokra  amire ma is hasznalod a geped.

A felhasznaloi igenyek alapvetoen nem valtoztak. Persze, mindig van hype, de a melyben ujra es ujra ugyanazok az igenyek koszonnek vissza. Nehany uj igeny kiszolgalhatova valt, a floppk idejeben nem volt tobb szereplos videochat, most meg mar van. De nem sok ilyen katartikus fejlesztes letezik, a legtobb dolog ugyanannak a dolognak a csiszolgatasa, elrontasa es kijavitasa.

Az oprendszer dolga, hogy kezelje a vasat es adjon egy felhasznaloi feluletet, amivel elerjuk a programokat, valamint kezelje a filerendszert, a memoriat, es utemezze a CPU-t. Ez a funkcionalitas miert kerul tobb tucat GB-ba? Raadasul mar visszafejlodott, mert a Win 11 kulalakjat nem tudod ugy magadra szabni, mint ahogy azt egy 98-ban kepes voltal megtenni. A Windowst mar a MS is leszarja, szoval en biztosan nem leszek a rajongoja. 

Szerintem:

- régen az átlagos fejlesztő képzettsége és intelligenciája jóval magasabb volt mint ma. "Elitebb" volt a szakma: eleve MSc volt a beugró szint.
- régen sokkal kevesebb absztrakciót adtak a (nem létező) keretrendszerek ezért sokkal több mindent kellett magadnak megoldani
- emiatt sokkal többet kellett tesztelned adott kód-komplexitásra vagy kódsorra vetítve
- egyszerűbbek és sokkal gyorsabbak voltak a tesztelési körök ezért teszteltél is
- mivel alacsonyabb volt az absztrakciós szint ténylegesen értetted (akár bit szintig) hogy pontosan mi történik (nézz ma meg egy springboot kódot és sírj) - amit egy junior pár hónap után már nyomogat és lövése nincs hogy mi történik, persze hogy sz@r

És igen, kisebbek voltak a rendszerek, jóval alacsonyabb volt a komplexitás - általában.

Btw - a nagygépes rendszerek már akkor se voltak feltétlenül kisebbek, 15-20 éve már komplett bank / repülőtársaság ment mainframe-en.
 

zászló, zászló, szív

Egyetértek.

Továbbmenve, a sok és vastag absztrakciós szint egy rakás problémát is okoz, ezért egy alapelvem lett, hogy a dolgokat ha csak lehet csupaszítsuk le, hogy annyira kevés legyen, ami éppen kell, de semmiképpen se több. A libek jelentős része olyan, hogy túlságosan el van bonyolítva, vagy behúz olyan függőséget, amire nem vágynék, vagy pont úgy használni ahogy szeretném nyakatekert.

Például az említett Spring olyan, amire nem vágyom. Javában írt webes dolgokra csináltam egy saját keretrendszert, amivel mindent meg tudok oldani, és untig elég nekem. 1 másodpercen belül indul, néhány osztály az egész, át lehet látni hogy mit csinál. Bele lehet írni a közepébe egy kis Javascriptet, ha kell, nem kényszeríti ki, hogy minden megfeleljen elefánttornyos architektek nedves álmának. Az mondjuk igaz, hogy nagyon nagy dolgot nem kellett csinálni még vele, alapból nem Webet programozok, csak annyit amennyit muszáj.

Régebben volt egy Dont Repat Yourself mánia korszakom, de rájöttem, hogy ha valahol emiatt be kell vezetni plusz absztrakciót, akkor lehet, hogy már nem éri meg. A Keep It Stupid, Simple az új jelszavam.

Most például egy rádiós mikrovezérlős játszós projekten gondolkodom. Vettem egy ESP32-t játszani hozzá, hogy kipróbáljam hogy megy rajta a Wifi. A getting started tutoriál meglepően jó minőségű, végig lehetett csinálni elakadás nélkül. Szóval ez egy hatalmas plusz 1 az ESP-nek. Viszont a hello world program kb 900 forrásfájl lefordításával állt össze, és a feltöltése több másodperc, mert nem kicsi a bináris. Alapból benne van egy FreeRTOS, ha jól láttam. Nem rossz alap, ha valami nagyon komplexet akarnék csinálni, de nem ehhez vagyok mikrovezérlőn szokva. Fontos lenne nekem a pontos időszinkron, és egy TCP oda-visszát egyelőre 200ms-nak mérek Wifin. Gondolom le lehetne valahogy szorítani, de komolyan azon gondolkodom, hogy egy egyszreű 433MHz rádiót vezérlek inkább nyersen egy kis AVR-rel, és még ha hibajavító kódolást kell implementálnom hozzá, akkor is lehet, hogy hamarabb szabadulok, mint hogy bekonfolnám rendesen a Wifit alacsony latencyre. És még sokkal pontosabb is lesz az óraszinkron, ha alacsony szinten kezelem a rádiót.

ESP32-nél az energiatakarékos mód tud nagy késleltetéseket okozni. Shelly plus-nál is fel-felmegy a ping 200ms-re, de ha kikapcsolom az ECO módot elég szép egyszámjegyű válaszidőket kapok, és azt olvastam, nem csak Shelly sajátosság, hanem kifejezetten ESP32. Lehet, valahogy érdemes lenne ütemezni, hogy ha nagyobb a hálózati forgalom, kapcsolja ki az ECO módot, majd kapcsolja vissza.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Köszi! Igen, még közel sem próbálgattam végig mindent, meg nem elemeztem ki az Internetet sem, ez a mentségem, hogy eddig nem hallottam erről! Pont tegnap csináltam csak végig a tutoriált és vegyes volt a benyomásom, hogy ezt akarom-e vagy inkább valami mást? Ki fogom próbálni a javaslatod!

Ezt kellett átállítani a csatlakozás előtt: ESP_ERROR_CHECK(esp_wifi_set_ps(WIFI_PS_NONE)); (Ezen FAQ szerint: https://espressif-docs.readthedocs-hosted.com/projects/esp-faq/en/lates… )

És 4ms körüli lett a TCP körbefordulás ideje: Measured latency ns: 4698230 micro: 4698 milli: 4

Kicsit változik, van hogy 5ms körül van. Ez szerintem elég jó lesz a célnak. Köszi még egyszer!

Ha így van a fejlesztő iparban amit írsz, ahogy írod, akkor miért van az, hogy a sok, munkát nagyban segítő, a hibák nagy részét kizáró, sok dolgot automatizáló nyelv mellett több a szar program (arányaiban), mint amennyi volt akkor, amikor ezek a nyelvek, rendszerek nem léteztek és jó programozók C-ben meg C++-ban tudtak csak fejleszteni?

Nem tudom, de be tudok dobni pár ötletet:

  • Lehet hogy az alapvetés is csak illúzió. Nem lett arányaiban több szar program, csak mivel a szoftverek mindenhol ott vannak, jobban benne vannak a hibák a köztudatban. Manapság az érdekesebb sebezhetőségeknek saját marketingnevük és logójuk van.
  • Komplexitási szint nagyot nőtt.
  • Mivel a piac is nagyot nőtt, és él a köztudatban, hogy infós diploma = magas fizetés, lehet, hogy valóban felhígult a szakma. De ezzel se fog senki semmit csinálni, mert egyenes következménye annak, hogy a szoftverek mindenhol ott vannak, a piac mérete megsokszorozódott. Ezzel egyrészt az oktatás sem tud lépést tartani, másrészt a felhasználók is nyilván spórolni akarnak.

A C már most sok éve visszaszorult, de nem minden területen. Sok low level meg rertróbarát projektnél még mindig a legjobb, mert a legminimalistább, leggyorsabban fordul, legkisebb hardverigényű lesz a bináris. Nem minden területen egyenlően fontos a paranoid memory safety mantra.

Egyébként nem zárom ki, hogy valaha én is megtanulom a Rust-ot, de nem mostanában lesz. Előbb megvárom, hogy hosszú távon megragad-e, nem ez is egy olyan hájplufi, ami valaha nagyon nagyra volt fújva, aztán kidurran. Különben is az NV vezér megmondta, hogy nem kell megtanulni már programozni, az AI majd megír mindent, az meg elvileg minden prognyelven kell tudjon memory safe kódot írni.

Egyébként ez a mai soydev divat, hogy ki akarnak nyírni mindent, régóta bizonyító stabil eszközöket is, C, C++, X11, stb.. Valahogy ez ilyen modern mánia lett, hogy mindig csak a legújabb hájpot kell tolnia mindenkinek, mintha kötelező lenne.

“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.”

( zsolt | 2024. 03. 06., sze – 19:34 )

Szerkesztve: 2024. 03. 06., sze – 19:46

Átnéztem a hivatkozott anyagokat és arra jutottam, hogy az egész hisztéria onnan jön, hogy a biztonsági hibák túlnyomó többsége címzési hibákból adódik.

A google szerint is megoldható lenne a probléma, ha a programozók a C++ nyelvnek csak egy részét használnák, ami egyébként tök memóriabiztos kódot tud generálni.

Ennek tetejébe az is könnyen megoldható, hogy a [] operátorok kódjába alapból beleforduljon egy határellenőrzés is, bár ez bizonyos esetekben elég komoly performancia csökkenést tud okozni.

Persze ha [] helyett a modern C++ iterációs módszereit használjuk a kódunk gyors lesz, még a kód is olvashatóbb lesz, de más logikával kell dolgozni.

A gond az, hogy arra nem lehet felkészíteni sem a fordítót, sem a containereket, ha valaki veszi pl. egy vector vagy string első elemének címét és pointer aritmetikával ír meg egy parsert, ami rosszul ellenőrzi a buffer végét. Ugyanakkor sokak szerint csak így lehet csak extrém hatékony parsert írni. bison, yacc már kiment a divatból.

Szóval, ha C++ fordítóval csak a nyelv modern részét használjuk, esetleg használunk [] operátorokat befordított határellenőrzéssel, nem írunk C-örökség pointer aritmetikát, akkor kb. ugyanott lehetünk, mint Rust-tal. A különbség, hogy ez C++-ban választás kérdése, Rust alatt pedig kényszer.

Ennek tetejébe az is könnyen megoldható, hogy a [] operátorok kódjába alapból beleforduljon egy határellenőrzés is, bár ez bizonyos esetekben elég komoly performancia csökkenést tud okozni.

Mert a "memory safe"-nek nevezett nyelvekben ez ám nincsen benne, nincs is performance hit!

Egyébként igen, régóta ezt mondom, hogy a C++-ban igenis lehet biztonságos ÉS hatékony kódot írni, csak a C++ túl szerteágazó nyelv. Hiába van az STL, ha még előjönnek a klasszik tömbök[], hiába van std::string, ha szembejönnek a char* stringek is (az ilyen gchar*-ról nem is beszélve), meg van ahova az STL is kevés, aztán jönnek a boost, stb.

Nem, nem lehet a fordítóba beletenni határellenőrzést (eleve, ha lehetne, akkor már rég beleteték volna...) Mert a tömb csak egy cím, a mérete nem utazik vele, semmi nem kényszeríti ki, hogy jelen kell lennie egy változóban és a compilernek tudnia kell, hogy melyik az.

Bele lehetne tákolni talán egy szabályt, hogy mindig passzolgatjuk a méretet egy mintának megfelelően, amit lehet statikusan ellenőrizni programmal, hogy be van-e tarva, csak akkor már pont ott fogunk tartani mintha eleve egy memóriát biztosan kezelő nyelvet választottunk volna, és főleg fontos, hogy a meglévő millió kódbázisra nem lehet utólag rákényszeríteni ilyen szabályokat.

A memóriabiztos nyelvekben ezzel szemben minden pointerhez tudja a fordító a méretét és többnyire a típusát is. (És ezért már nem is hívja pointernek, de attól a referencia az az, vagy legalábbis olyasmi.)

>Persze ha [] helyett a modern C++ iterációs módszereit használjuk a kódunk gyors lesz, még a kód is olvashatóbb lesz, de más logikával kell dolgozni.

Nem lesz gyors, az index szerint memóriában ugrálva iterálásnál nem találtak fel gyorsabbat és nem is lehet (kivéve a párhuzamosságot, de az egy másik végtelen problémakör és csak nagyon nagy méreteknél válik hatékonnyá). A méretellenőrzés overheadje viszont a legtöbb esetben elhanyagolható, mert a compiler felismeri a mintákat, és valójában nem ellenőriz minden iterációban például, mert tudja, hogy a határ fix értékű úgyis. De ha mégis kell ellenőrizni, akkor az ellenőrzés tök olcsó, mert a méret a pointerrel együtt utazik, egyazon cache line-ban van, a betöltése nem okoz szinte semmi plusz költséget. Vagy ha egymás után sokszor kell, akkor a compiler beteszi a határt egy regiszterbe és egy másik utasítással átlapoló módon futtathatja a processzor az ellenőrzést kb fél CPU órajel alatt.

Az indexeléssel szemben az objektumokon iteráló dolgokkal könnyen előfordulhat, hogy nem egy cache sorban vannak, ugrálni kell a RAM-ban olvasáskor és akár csak emaitt többszörös lassúság lehet a vége funkcionálisan ekvivalens kódnak.

Mi a my_vector típusa? Milyen tárgykódra fordul? Gyorsabbra mint egy számláló szerinti iterálás (for(int i=0;i<n<++i)), amihez CPU szupport van már a mikrovezérlőkben is (inkrement, határ ellenőrzés és ugrás 1-2 CPU utasítás szokott lenni)? Biztos vagy benne? Ha be akarod bizonyítani ne nekem kelljen már utánajárni, hanen mondd meg, hogy mire gondolsz!

Nem, nem lehet a fordítóba beletenni határellenőrzést (eleve, ha lehetne, akkor már rég beleteték volna...)

Na de hát ezt az ÖSSZES C/C++ fordító tudja! Bármelyik képes ASAN kódot hozzáfordítani.

meglévő millió kódbázisra nem lehet utólag rákényszeríteni ilyen szabályokat.

Mondod Te, miközben Bellard meg unalmában összedob egy C fordítót, ami csuklóból tudja ezt (és brahiból a nem túl kicsi Linux kernel forrás fordításával demonstrálta, hogy a gyakorlatban is működőképes a megoldása).
És azt se felejtsük el, hogy bármilyen meglévő kódbázist képes a valgrind utólag ellenőrizni, annélkül, hogy a forráshoz akár egy ujjal is hozzá kéne nyúlni.

Az sprintf (celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev); sort mégis hogyan fordítod határellenőrzéssel?

Linkeld be lécci ezt a csodafordítót, hogy mit tud! Bellardot tisztelem és kedvelem, de csodát tenni ő se tud!

Az ASAN továbbra is arra jó, hogy az olyan hibákat, amit menedzselt nyelvekben nem is léteznek, runtime észreveszi. Ráadásul csak valószínségi alapon, nem 100% biztonsággal. A túlcímzések meg olyanok, hogy sokszor csak trükkös inputra jönnek elő, ha nincs olyan teszteseted sosem fogod meg. Szerinted ez tényleg egyenértékű?

És még hozzá kell venni a metaadatot, hogy melyik változó melyik puffernek a hossza, a fordítónak tudnia kell ezt és vissza kell ellenőriznie, hogy korrektül volt-e kitöltve. Nyilván pont triviális feladat, ahogy bzt állítja. Általánosságban nem megoldható, ezért nincsen ilyen fordító és nem is lesz. Elvi képtelenség.

Lehetséges a C-nek egy olyan alhalmazát létrehozni, amiben bizonyos automatikusan ellenőrizhető szabályok betartása esetén nincsen túlcímzés. És akkor az olyasmi lesz mint a Rust, amiben eleve gyárilag nincs, csak sokkal bonyolultabban. És ebbe a keretbe nem fogod tudni beleszuszakolni a meglévő soktíz éve fejlődő kincset érő kódbázist.

Az sprintf (celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev); sort mégis hogyan fordítod határellenőrzéssel?

Hahahahaha! Te nem fordítottál sok C programot ugye? Ehhez még csak ASAN sem kell, a C fordító már fordításkor kiszúrja!

Ime a bizonyíték:

$ cat test.c
#include <stdio.h>

int main(int argc, char **argv)
{
    char celbufferpointer[10], *termeknev = "kutyagumi";
    int n = 1;

    sprintf(celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev);

    (void)argc; (void)argv;
    return 0;
}
$ gcc -g -ansi -pedantic -Wall -Wextra test.c -o test
test.c: In function ‘main’:
test.c:8:41: warning: ‘%s’ directive writing 9 bytes into a region of size 2 [-Wformat-overflow=]
    8 |     sprintf(celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev);
      |                                         ^~
test.c:8:5: note: ‘sprintf’ output 32 bytes into a destination of size 10
    8 |     sprintf(celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Látod? Már fordításkor magától észreveszi a határtúllépést a fordító!

Most jöjjön ugyanez dinamikus memóriafoglalással is, nehogy szó érje a ház elejét:

$ cat test.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
    char *celbufferpointer, *termeknev = "kutyagumi";
    int n = 1;

    celbufferpointer = malloc(10);
    sprintf(celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev);

    (void)argc; (void)argv;
    return 0;
}
$ gcc -g -ansi -pedantic -Wall -Wextra test.c -o test
test.c: In function ‘main’:
test.c:10:41: warning: ‘%s’ directive writing 9 bytes into a region of size 2 [-Wformat-overflow=]
   10 |     sprintf(celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev);
      |                                         ^~
test.c:10:5: note: ‘sprintf’ output 32 bytes into a destination of size 10
   10 |     sprintf(celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Itt is kiszúrta, és még csak ASAN sem kellett hozzá!

De ha a statikus elemzésen mégis átcsúszna, és a fordító nem tudna ASAN-t esetleg, futás időben a valgrind akkor is megfogja, annélkül, hogy bármifélét kéne a forrásba gányolnod, sőt, ez bármilyen már lefordított binárisba is beteszi utólag a határellenőrzést (mégegyszer kiemelném: bármilyen már lefordított binárisba, utólag):

$ valgrind ./test
==1209363== Memcheck, a memory error detector
==1209363== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1209363== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==1209363== Command: ./test
==1209363== 
==1209363== Invalid write of size 2
==1209363==    at 0x484FF23: memmove (vg_replace_strmem.c:1410)
==1209363==    by 0x48D8168: memcpy (string_fortified.h:29)
==1209363==    by 0x48D8168: __printf_buffer_write (Xprintf_buffer_write.c:39)
==1209363==    by 0x48E0396: __printf_buffer (vfprintf-process-arg.c:501)
==1209363==    by 0x48FC2D1: __vsprintf_internal (iovsprintf.c:62)
==1209363==    by 0x48DD3C4: sprintf (sprintf.c:30)
==1209363==    by 0x109196: main (test.c:10)
==1209363==  Address 0x4a6804a is 0 bytes after a block of size 10 alloc'd
==1209363==    at 0x4843788: malloc (vg_replace_malloc.c:442)
==1209363==    by 0x109173: main (test.c:9)
==1209363==
 ...

Látod? Nemcsak azt mondja meg, hogy a test.c 10. sorában történt a határátlépés, hanem még azt is, hogy az adott buffer a test.c 9. sorában lett lefoglalva! És ez működik bármilyen nyelvvel, bármilyen már lefordított binárissal!

Mégegyszer: az állításoddal ellentétben a határellenőrzés nemcsak hogy lehetséges, de ráadásul évtizedek óta bevett gyakorlat, és ehhez nem kell a C forrásba semmit sem turkálni, annélkül is működik!
Az évtizedek óta meglévő tesztelő eszközök meg nyelvtől tök függetlenül, már lefordított binárisban is képesek észlelni azt!
Az, hogy ezt a nyelvbe kéne beletákolni ahhoz, hogy legyen, egyszerűen szín tiszta hazugság, marketing bullshit, semmi más.

Az, hogy mutatsz példát, ahol működik nem jelenti azt, hogy mindenhol működik. A Valgrind a félrecímzést akkor szúrja ki, ha értelmetlen helyre történik. Ha véletlenül egy másik változót írsz felül, azt nem veszi észre. Te meg pisloghatsz, hogy mitől változott meg egy változó értéke, aminek nem kellett volna.

Parttalan ez a vita, ha nem érted a különbséget aközött, hogy heurisztikák többnyire észrevesznek valamit, vagy a Valgrind általában kiszúrja a hibát, ha triggerelődik a tesztfutás alatt, és aközött, hogy elvileg nem lehetséges egy adott típusú hibának előfordulni a rendszerben.

trükkös.c

extern void rendeles(int n, const char * termeknev);
int main(int argc, char **argv)
{
    int n = 1;
    rendeles(n, "kutjagummi, de nagyon hosszu, minden bufferen tulmutato merete van, tobb mint 30 hosszu, de a compilernek ne mondd meg, pssszt!");
    (void)argc; (void)argv;
    return 0;
}

rendeles.c

#include <stdio.h>
void rendeles(int n, const char * termeknev)
{
    char celbufferpointer[30];
    sprintf(celbufferpointer, "%d darab %s-t rendeltünk", n, termeknev);	
}

Fordítás és futtatás:

$ gcc -g -ansi -pedantic -Wall -Wextra trukkos.c rendeles.c 
$ ./a.out 
*** stack smashing detected ***: terminated
Aborted (core dumped)

Ennyikeh

Ha véletlenül egy másik változót írsz felül, azt nem veszi észre.

És a Go meg a Rust meg a többi csodanyelv hogy is veszi ezt észre? Mutass egy konkrét példát, ahol van két azonos típusú változó, a program a rosszba ír, és ezt észreveszi bármilyen fordító! BÁRMILYEN.
Ha meg arra gondolsz, hogy egy másik változó címzésekor íródik felül, akkor fuss neki mégegyszer, hogy mi is az az ASAN és mire való, gugli a barátod! De elárulom, ezt az esetet észreveszi a C fordító statikus ellenőrzése és a valgrind is!

Parttalan ez a vita

Valóban értelmetlen, mert jól látszik, hogy az alapfogalmakkal sem vagy tisztában. Csak dobálózol itt olyan dolgokkal, amiket valahonnan hallottál, de valójában lövésed sincs, mit jelentenek. Már meg ne sértődj, de olyan vagy, mint egy indiai copy'n'paste huszár.

Az meg kifejezetten hazugság megint, hogy a fenti példádra ne működne a határellenőrzés (sőt, úgy működik, hogy a forráshoz hozzá se kellett nyúlni!):

$ gcc -g -ansi -pedantic -Wall -Wextra -fsanitize=address trukkos.c rendeles.c
$ ./a.out 
=================================================================
==1223976==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x709dfb90903e at pc 0x709dfe07eee9 bp 0x7ffc67576a60 sp 0x7ffc675761f0
WRITE of size 150 at 0x709dfb90903e thread T0
    #0 0x709dfe07eee8 in __interceptor_vsprintf /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1765
    #1 0x709dfe07f0ff in __interceptor_sprintf /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1808
    #2 0x5645eacaf2d4 in rendeles /home/bzt/rendeles.c:5
    #3 0x5645eacaf1c2 in main /home/bzt/trukkos.c:5
    #4 0x709dfde43ccf  (/usr/lib/libc.so.6+0x25ccf) (BuildId: c0caa0b7709d3369ee575fcd7d7d0b0fc48733af)
    #5 0x709dfde43d89 in __libc_start_main (/usr/lib/libc.so.6+0x25d89) (BuildId: c0caa0b7709d3369ee575fcd7d7d0b0fc48733af)
    #6 0x5645eacaf0c4 in _start (/home/bzt/a.out+0x10c4) (BuildId: f5db83cafa76395ea660b7011a77367a4f6bb509)

De természetesen a valgrind is megfogja, még akkor is, ha ASAN nélkül lett fordítva:

$ valgrind ./a.out 
==1222365== Memcheck, a memory error detector
==1222365== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1222365== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==1222365== Command: ./a.out
==1222365== 
*** stack smashing detected ***: terminated
==1222365== 
==1222365== Process terminating with default action of signal 6 (SIGABRT): dumping core
==1222365==    at 0x491032C: __pthread_kill_implementation (pthread_kill.c:44)
==1222365==    by 0x48BF6C7: raise (raise.c:26)
==1222365==    by 0x48A74B7: abort (abort.c:79)
==1222365==    by 0x48A8394: __libc_message_impl.cold (libc_fatal.c:132)
==1222365==    by 0x499773A: __fortify_fail (fortify_fail.c:24)
==1222365==    by 0x4998A55: __stack_chk_fail (stack_chk_fail.c:24)
==1222365==    by 0x1091CB: rendeles (rendeles.c:6)
==1222365==    by 0x206F746174756D6B: ???
==1222365==    by 0x762065746572656C: ???
==1222365==    by 0x62626F74202C6E60: ???
==1222365==    by 0x303320746E696D1F: ???
==1222365==    by 0x2C757A73736F681F: ???
==1222365==

Tessék, itt az egyértelmű, tagadhatatlan bizonyíték, hogy nem kell szétbarmolni és túlbonyolítani egy nyelvet ahhoz, hogy legyen memóriaellenőrzésed! És felhívnám a figyelemed, hogy TE adtad a példát, én semmit sem változtattam a forráson, egyetlen betűt sem kellett hozzátennem azért, hogy ez működjön!

A baj az, hogy fogalmad sincs, hogy működik valójában a határellenőrzés (és a Rust fordító sem csinál mást, mint hogy csont ugyanazt az ellenőrző kódot generálja, mint a "-fsantize=address" hatására a gcc), nem tudod, mi a különbség a szintaktikai és szemantikai ellenőrzés között, és mégis próbálod osztani itt az észt.

De hát most pont azt mutattad meg, hogy ez nincs fordítási időben kiszűrve, csak futási időben van szép információ róla, hogy memóriahibát okozott a program - akkor már régen késő.

Azt mutasd meg, hogy hogyan szűri ki fordításkor ezt a hibát a fordító! Hiszen arről beszéltél, hogy ezt simán megcsinálja.

Azt mutasd meg, hogy hogyan szűri ki fordításkor ezt a hibát a fordító! Hiszen arről beszéltél, hogy ezt simán megcsinálja.

Tévedés! Én azt állítottam, hogy a fordító képes belefordítani a határellenőrzést, annélkül, hogy a nyelvhez vagy a forráshoz hozzá kéne nyúlni! Az, hogy a kolléga nagypofával belengetett "sprintf" példáját már fordításkor is megfogja a gcc, már csak hab a tortán.

De ha már kötözködés, ami azt illeti, hiába hazudjátok az ellenkezőjét, még a Rust sem képes futás időben kiszűrni a hibákat (mondom, nem tudjátok mi az a szemantikai ellenőrzés), kurva sok a bejelentett és még mindig nyitott runtime error (400 fölött!). Ezek közül jelentős a memóriával kapcsolatos hibák száma, mint például ez vagy akár ez, amit 5 éve nem képesek megoldani

cargo run
   Compiling stack_overflow v0.1.0 (/d/stack_overflow)                                                                        
    Finished dev [unoptimized + debuginfo] target(s) in 7.08s                                                                 
     Running `target/debug/stack_overflow`

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

Csupán csak az, hogy egyáltalán léteznek ilyen hibabejelentések, önmagában empirikusan cáfolja, hogy a Rust memóriabiztonságos nyelv lenne. PONT.

Miféle provokáció? Bizonyítottad az alkatlanságodat, ez hol kéne, hogy engem bosszantson? Bocs, tényleg nem akartam bunkó lenni, de annyira iszonyatosan magas labdát dobtál fel... Tudod, az értelmesebbje előbb körbenéz, aztán kérdez csak.

Egyébként meg még mindig nem mutattál PoC-ot arra, hogy Rust hogy veszi észre a hibás változóba írást, és arra sem tudtál mit mondani, hogy egy állítólag memóriabiztos nyelvben hogy lehetnek mégis stack overflow runtime errorok. Arra sem reagáltál, hogy a "meglévő millió kódbázisra nem lehet utólag rákényszeríteni ilyen szabályokat" konkrétan több ellenpéldával is cáfoltam... Ezek után hogy vegyelek komolyan?

Összekeversz egy másik hozzászólóval. Stack overflow mindig lesz, mert ez egy logikai hiba (pl. végtelen rekurziót csinálsz és elfogy a stack), amit egyébként kiválóan észrevett a Rust futás időben és szépen kiléptette az alkalmazást, nem pedig crash-elt. Sőt, ahogy néztem, az unmanaged kódra is csináltak mitigációt. 

amit egyébként kiválóan észrevett a Rust futás időben és szépen kiléptette az alkalmazást, nem pedig crash-elt.

LOL. Na akkor direkt a kedvedért idemásolom az általam linkelt issue szövegét (kiemelés tőlem):

If so, then it would be better for it to report the stack overflow, instead of seg faulting.

Az issue máig megoldatlan.

Oké, én a másik hibajegyet néztem, abban nem volt segfault, csak sima runtime error. Hogy egyébként még érdekesebb legyen, itt pl. pont úgy száll el, ahogy kéne, a srác viszont m-es (arm-os) mac-es gépen fordította. Ez tényleg furcsa, ilyen sok múlna az architecturán?

 

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gi…

#include <stdio.h>
void printByPointer(const char * msg, int * arg) { printf("%s%d\n", msg, *arg); }
void incrementByPointer(int * arg) {
  /* Exact value depends on layout of actual compiler. see commented out printf below.
     The point is that it is possible to overwrite an other variable by error. */
  (*(arg+4))++;
}
int main(int argc, char **argv)
{
    int a = 112, b=112;
    (void) argc;
    (void) argv;
/*    printf("addressdiff: %d\n", (int)(&b-&a) );*/
    incrementByPointer(&a);
    printByPointer("a erteke: ", &a);
    printByPointer("b erteke: ", &b);
    return 0;
}

$ gcc -g -ansi -pedantic -Wall -Wextra -fsanitize=address trukkos2.c 
$ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/9/libasan.so  ./a.out 
a erteke: 112
b erteke: 113

Pedig mintha valamelyik sérülékenység ellenőrző tool is azt csinálná, hogy keresi a binárisban, bekerült-e az a metódusnév, ami bizonyos hívások wrappelésére van használva valamelyik fordító által, vagy pedig olyan paraméterrel fordították a kódot, hogy ne kerüljön bele. 

Ja mondjuk, amire emlékszem, az pont nem tömb, hanem stack-protector paraméter volt
https://github.com/scottyab/rootbeer/issues/77

ha valaki veszi pl. egy vector vagy string első elemének címét és pointer aritmetikával ír meg egy parsert

Na én pont a pointer-aritmetikás csávó vagyok, ha C-ről van szó. Soha nem használok []-t.

C++ esetén +1 a ,,modern" iterációs módszereknek: onnan tudod, hogy szar a kódod, hogy magad iterálsz! ;-)

Persze ez egy picit sarkos, hiszen a programozón múlik, mit használ ki a C++ lehetőségeiből. Láttam olyan driver forrást C++-ban (WAN kártya driver), ami tulajdonképpen C-ben volt írva, a C++ feature-jeiből csak a namespace-eket használta. Az ilyesmit nem tekintem ,,valódi" C++ programozásnak.

"ha [] helyett a modern C++ iterációs módszereit használjuk a kódunk gyors lesz,"

de lehet nagyságrendekkel lassabb, mint a primitív módszerrel, ez volt egy vicces ilyen videórészlet (js tömb fikázás vs fancy megvalósítás):
https://youtu.be/NmHUjxKpD90?t=501

Ahol nem számít, ott nem számít és szépen / máshogy olvasható lesz.
De ahol kritikus a teljesítmény, ott meglesz továbbra is a helye a barbár kódnak, ahol nem hívódik meg ezer másik eljárás a háttérben.
A felhőben is, amit megkapják a számlát.

Ezt a leftPad megvalósítást továbbra sem értem. Ugye ez a fajta művelet: "str=ch+str" iterációban négyzetesen skálázódik a szükséges hosszal. Ennek a problémának az elkerülésére találták fel a StringBuilder-t, és soha nem értem, hogy JS-ben mitől jön rá a compiler (interpreter), hogy erről van szó, hogy el tudja kerülni a négyzetes skálázódást?

( persicsb | 2024. 03. 06., sze – 21:38 )

https://storage.googleapis.com/gweb-research2023-media/pubtools/pdf/704…

Ha elolvasod a whitepapert, a C/C++ közösen van említve:
 

Memory safety bugs are responsible for the majority (~70%)
of severe vulnerabilities in large C/C++ code bases

....

In unsafe languages such as C/C++, it is the programmer’s
responsibility to ensure the safety preconditions are met to
avoid accessing invalid memory.

...

 

Amit amúgy a C++ memóriabiztonságáról mondanak, az egy az egyben alkalmazható a C-re is, szóval azzal sem számolnak.

( locsemege v | 2024. 03. 06., sze – 22:12 )

Ahogy csökken az emberekben a bizalom, nőnek ki a földből a kerítések. Csökken a szabadság, nő a kontroll. Elveszítjük végül az egész életet.

Hagyják békén a pointereket! Csináltam én már olyat, hogy egy ötletszerűen kiválasztott változóm címét tettem a pointerbe, mert nem használtam fel az értékét az adott helyen, csak az volt a lényeg, hogy ne legyen NULL. :) A későbbiekben aztán gondolom, kapott valami valid értéket.

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

Kit érdekel a Gugli problémája? A cikk arról szól, hogy "halál a C nyelvre", és hogy modern nyelvekkel, mint pl. a Rust kéne kiváltani.

Rendicsek, akkor lássuk, képes-e az új csodanyelv megoldani olyan dolgokat, amikre a C-t használják! Ja, hogy nem is képes rá... ÜBER MEGA ROTFL! :-)

( buki | 2024. 03. 07., cs – 09:00 )

Dömös Zsuzsanna már sokadik cikkben tesz hitbizonyságot arról, hogy nemcsak egyszerűen nem tudja mi a különbség C és C++ között, de kimondottan büszke is erre

Ez amúgy pontosan hol derül ki?

Csak mert én elolvastam a cikket és nem támadt ilyen érzésem.

Science for fun...

( PestiSrac | 2024. 03. 07., cs – 13:28 )

Szerkesztve: 2024. 03. 07., cs – 20:15

En pedig ugy latom Ritter amokfutasa folytatodik. Nem ez az elso, es altalaban nem zavartatod magad, amikor tenyszeruen linkelve van h nem igaz amit mondasz, vagy kiderul, hogy el sem olvastad, meg sem hallgattad. de elfogadom az elnezes keresedet, amit a poszt vegere toltal. :)

Arra ugyanis most sem vetted a faradsagot, hogy a rovidke blogbejegyzest tenylegesen is elolvasd. Vagy ilyen dobbenetesen feluletes vagy, vagy az angol tudasod nem valami acelos. A google blogposztja ugyanis mar az elso sorban linkelni azt az atfogo whitepapert, aminek tulajdonkeppen a kivonatat olvasod a blogposztban. A lenyeg h a C es a C++ egy kalap alatt van.

"Webelieve that a Secure-by-Design approach is required for high assurance memory safety, which requires adoption of lan guages with rigorous memory safety guarantees. Given the long timeline involved in a transition to memory-safety languages, it is also necessary to improve the safety of existing C and C++ code bases to the extent possible, through the elimination of vulnerability classes."
 

( bzt | 2024. 03. 08., p – 16:34 )

Szerkesztve: 2024. 03. 08., p – 16:37

Na kérem, lehetőséget adok Nektek a bizonyításra, kiírtam egy versenyt!
https://hup.hu/node/184598

A lényeg, bármilyen nyelven (Rust, Go stb.) készíteni kell egy rendszerprogramot, ami másodpercenként növel egy számlálót a képernyőn. Ennyi.
A végén meg összehasonlítjuk majd, melyik nyelv fordítója generálta a legjobb megoldást.