C/C++

Írtam egy ilyet:

void nfree(void **p) {

    if (p) {
        free(*p);
        *p = NULL;
    }
    return;
}

Nem akarok típust cast-olni minden híváskor, és nem akarok emiatt warningot látni. Valahogy a realloc(), free() megoldja, hogy a fordító nem nyüszít, bármilyen típusú pointert is adok át. Néztem az stdlib.h-t is, de talán valamilyen attribútum lesz a megoldás, viszont nem tudom mi és miképp.

Mit kell tennem, hogy például ez ne adjon warning: passing argument 1 of ‘nfree’ from incompatible pointer type [-Wincompatible-pointer-types] figyelmeztetést? Már a cast-oláson illetve a warningok globális kikapcsolásán túl.

Megoldás

Az első hozzászólásban apal által adott megoldás nyerte el tetszésemet. Lefordult warning nélkül, ami persze érthető.

Köszönöm a segítséget!
 

Írtam egy programot, ami annyit csinál, hogy egy fájlba ír uint64_t számokat. (pontosabban prímszámokat, egy jó nagy fájlt csinálnék, amiben prímszámok vannak). kb. 2 hét alatt eljutott odáig, hogy a fájl mérete 2GByte lett, és nem íródik bele semmi. Érdekes, mert úgy viselkedik, mintha írna a fájlba, semmi leállás, csak a fájl nem növekszik, megállt 2147483647-nél. (minden 100000. prímnél kiírja a számot, és azt hogy hányadik).
Azt hittem, hogy ez a 2GB mérethatár már a régmult problémája. Ubuntu 18.04 32bit, ext3 fájlrendszer, gcc-7.5.0 a rendszer. Nem hiszem, hogy a rendszer korlátozná a 2GB-nál nagyobb fájlokat, hiszen ennél jóval nagyobb fájlok is vannak használva másegyéb programokkal.
A gcc/glibc cuccnak lenne ilyen határa, vagy esetleg valami fordítási direktíva kéne még?

A POSIX-UEFI egy minimális (~132K a forrás), ANSI C keretrendszer, ami kényelmesebbé és egyszerűvé teszi az UEFI alkalmazások fejlesztését Linux alatt. Szabad és Nyílt Forráskódú, a licensze MIT, így akár kereskedelmi termékekben is használható.

https://gitlab.com/bztsrc/posix-uefi

Kettős célja van:

- egyrészről biztosít egy fordítókörnyezetet (GNU/make Makefile), ami lehetővé teszi az UEFI alkalmazások fordítását POSIX kompatíbilis oprendszerek alatt (nincs szükség a bloated EDKII-re)

- másrészről szállít egy függvénykönyvtárat, ami biztosítja, hogy az UEFI alkalmazásodban szabványos POSIX libc hívásokat használhass UTF-8 sztringekkel (úm. fopen, fprintf, rmdir, malloc, setjmp/longjmp stb.)

- a függvénykönyvtár mellé jár egy C header fájl is, ami a libc definíciókon és prototípusokon túl az összes fontosabb UEFI definíciót is tartalmazza, de az ANSI C szabvány nevezéktan szabályainak megfelelően (pl. WCHAR helyett wchar_t, vagy EFI_BOOT_SERVICES helyett efi_boot_services_t a típus), ezért semmilyen további headerre nincs szükség.

- bónuszként jár hozzá pár függőség nélküli parancssoros segéd, amikkel UEFI szabványos ROM képek vagy GPT+ESP lemezképek állíthatók elő a lefordított programodból. Persze ezek nékül is használható, ezek csak grátisz toolok.

A Makefile úgy lett megírva, hogy autodetektálja a fordítót (Clang és host native gcc is támogatott), és hogy kell-e keresztfordítani, valamint tartalmazza a szükséges linker scripteket is (x86_64 és AArch64 platformok támogatottak, RISC-V experimental státuszú, új architektúra bármikor különösebb módosítás nélkül, egyszerűen hozzáadható). A függvénykönyvtár minimális (lefordítva pár Kb csak), nem teljes libc, inkább csak egy wrapper az UEFI GUID-es interfésze fölé. A repóban található jópár példaprogram, olyanok mint könyvtár listázása; diszkek alacsony, szektor szintű elérése; PNG kép megjelenítése GOP framebufferen; vagy éppen egy ELF bináris futtatása a boot környezet hátrahagyásával.

Ha valakinek kapóra jön (mert tudomisén épp rootkitet hegeszt a szabadidejében suttyomban :-) ), az használja egészséggel!

bzt

Üdv,

Írtam egy PICO-8-szerű, retro virtuális konzolt (ezen az oldalon ez eléggé többértelmű, szóval konzol, mint NES, Famicom, PS, XBox stb.). A célja a kezdő programozók segítése, hogy gyorsan és könnyen sikerélményekkel szolgáljon nekik, mint anno a Commodore és társai az én időmben.

https://bztsrc.gitlab.io/meg4/

Néhány fícsör a teljesség igénye nélkül:

- Szabad és Nyílt forráskódú (GPL, gitlab repó)

- támogatja a BASIC-et (akárcsak bármelyik 80-as évekbeli home computer), Lua-t (mint a többi virtuális konzol), de programozható C-ben (saját natív nyelve) illetve Assemblyben is

- többnyelvű, UTF-8 támogatással, a beépített súgó természetesen magyar nyelven is elérhető (ehhez írtam egy MarkDown megjelenítőt)

- akárcsak a többi virtuális konzol, beépített szerkesztőkkel rendelkezik (szövegszerkesztő, szprájtszerkesztő, zeneszerkesztő, stb., de még debugger is van benne)

- de ha valaki ragaszkodik a kedvenc eszközéhez, a könnyű átjárhatóság érdekében rengeteg formátumot támogat (PNG, Amiga MOD, MIDI, Tiled TMX, BDF, PSF, de még PICO-8 és TIC-80 kertridcsek is importálhatók vele)

- a rendelkezésre álló függvénykönyvtár terebélyes, átfogó és hatékony (szokásos grafikai primitíveken túl Bezier-ívek, teknőcgrafika, 3D-s labirintus és mátrix meg kvaterniófunkciók pl.)

- a programozást nagyon leegyszerűsíti és szórakoztatóvá teszi a szövegszerkesztés közbeni segéd (gépelés közben mutatja, milyen paraméterei vannak az API-nak)

- részletes, jól megírt dokumentációval rendelkezik: https://bztsrc.gitlab.io/meg4/manual_hu.html

Jelenlegi formában még kezdetleges, itt-ott kissebb bugokra kell számítani, de már elég jól használható. Bináris futtathatók is letölthetők (statikusan linkelt Windows és Linux, valamint dinamikusan linkelt Ubuntu és Raspberry Pi .deb csomagok formájában). Telepítést nem igényel (portable executable). Natív futtathatókon túl böngészőre optimalizált WebAssembly port is elérhető.

Ha valaki kipróbálná, akkor klikk a honlapra, és húzzátok rá valamelyik flopi képet az emulátorra! Egyelőre kevés példaprogram van hozzá, de azok remélem jól példázzák, mire képes.

Kíváncsian várom a véleményeiteket!

bzt

ps: ha valaki kérdezné, miért nem TIC-80, akkor a válaszom az, hogy azért nem, mert az rettentő bugos és nem tud magyarul. Sőt mi több, a magyarítása nem is lehetséges (beégetett sztringek és ékezetes karakterek teljes hiánya miatt).

A napokban egy olyan érdekes C fordító forrása került fel a GitHub-ra, ami egy szokatlan sajátosságával emelkedik ki a szóban forgó nyelvhez készült kompilerek végtelen sorából. A SectorC különlegességét ugyanis nem az adja, hogy minden másik társánál gyorsabb kódot generál vagy hogy a legújabb nyelvi sajátosságokat is támogatja, hanem az, hogy simán elfér egy rendszerbetöltő szektorban is - ugyanis 512 bájtban is elfér.

https://xorvoid.com/sectorc.html

https://github.com/xorvoid/sectorc

Forrás:
https://prog.hu/hirek/6475/sectorc-boot-sector-c-fordito-compiler-512-bajt-kicsi

Sziasztok,

ESP32 mikrokontrollerre szeretnék egy (általános) fejlesztői környezetet írni, amiben már kész vannak az alap dolgok, utána csak az üzleti logikával kéne foglalkozni. Az alapok megvannak, már működik, de szeretném fejleszteni. Ehhez tartozik egy webes felület is. Korábban ez "kézzel írt" html és javascript volt, ami fájlonként volt 7-10 kb. Pl ez: https://github.com/redakker/blecker/tree/main/html
Ahhoz, hogy egységesebb legyen gondoltam választok egy javascrip framework-öt, így jutottam el a Svelte-ig, ami az egész mindenséget bele tudja fordítani egy darab html fájlba. Így a kiszolgálás is egyszerűsödik, de a fájl 100kb-osra nőtt.

Tehát a probléma: Az ESP-nek 100kb kiszolgálása már nehézséget okoz. EspAsyncWebserver library-t használnék.
Kérdés: Mit lehet ez ügyben tenni?

Sajnos a C++ ismereteim még nem elegek ennek a problémának a megoldásához, ezért kérek segítséget.
Kérdeztem a chatGPT-t is, de nem voltam vele sikeres.

Tehát van egy PROGMEM változóm, ami be a build során bekerül a HTML kód.
 

const char data_index_html[] PROGMEM = R"=====(
<!DOCTYPE HTML><html>
...
nagyon szép admin oldal, html, javascript, css
...
</html>
)=====";

Az egészet szeretném egy objektumba zárni:

#include <ESPAsyncWebServer.h>

class WebServer {
  public:
    WebServer(int port) : server(port) {}

    void begin() {
      server.on("/", HTTP_GET, [this](AsyncWebServerRequest *request){
        handleRoot(request);
      });
      
      server.begin();
    }

  private:
    AsyncWebServer server;

    void handleRoot(AsyncWebServerRequest *request) {
      String response = data_index_html;
      request->send(200, "text/html", response);
    }

   
};

És üres lapot kapok. Valószínűleg memória gondok lesznek. Próbáltam feldarabolni és streamként küldeni, de nem sikerült (nem az elv miatt).

Szóval tudna valaki támpontokat, esetleg kódrészletet írni, hogy merre induljak?

Köszönöm!

Üdv: redman

Sziasztok!

Tud erre valaki magyarázatot adni, miért csak 15 hosszú lehet az interface név?

   Linux define value in /usr/include/linux/if.h.
   #define IFNAMSIZ        16
   FreeBSD define value in /usr/include/net/if.h.
   #define IFNAMSIZ        16

C++-ban kellene kódot írnom (hobby), de még a C sem az erősségem.

Próbálom megérteni, hogy elméleti alapon miért rossz a C++ következő kód:

const char* fix_string = "FIX STRING";
char* szoveg = fix_string;

Nem értem, hibás ez? Amit mondani akarok vele, hogy van egy szöveges konstansom, ami sohasem változhat, és van egy másik szöveges változóm, ami felvehet tetszőleges értéket, például a fix értéket is.

Hol rontom el a gondolatmenetemet?

Az uno2iec projectet próbálom életre lehelni. Ebben egy Arduino Nano kommunikálna a PC-n egy QtCreator-ban készült cpp kóddal.

Sajnos a kód nem működik megfelelően, de még a hibát sem tudom megkeresni, mivel a cpp kód indítása után egy kis idő elteltével eltűnik a /dev/ttyUSB0 eszköz. Ilyenkor hiába húzom ki, és dugom be újra, a /dev/ttyUSB* nem lesz többé. Az újraindítás után minden rendben működik.

A cpp kód normál felhasználó nevében fut, de a felhasználónak joga van használni a soros portot. Így gondolom elrontani is joga van.

A kérdésem: hogyan lehet annyira elrontani a soros port kezelését, hogy tönkrevágja az új eszközök felismerését, és mit lehet ilyenkor kezdeni az újraindításon kívül az USB-vel, hogy újra működjön?

Sziasztok, Android source build-hez ért valaki?

Emulátor környezetben szeretnék tesztelni egy EVS_APP nevű programot, ami egy native app és az Android source code-jának a része a packages folderben:

https://cs.android.com/android/plat...r:packages/services/Car/cpp/evs/apps/default/

Sajnos rengeteg belső libet használ, ezért csak a teljes forrás részeként fordítható.

Ez egy automotive alkalmazás. Nagy nehezen találtam egy lunch target-et, amivel elindult egy Automotive emulátor: sdk_car_x86_64

Viszont fogalmam sincs, hogyan lehetne ezt (és dependenciáit) hozzáadni a buildhez. 

Ha valakinek van ötlete, szívesen fogadom.