- Bivalyerős lett a Poco F6 és F6 Pro
- Samsung Galaxy S23 Ultra - non plus ultra
- Asus Zenfone 10 - kicsit más az új kicsi
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Motorola Edge 30 Neo - wake up, Jr...
- Android szakmai topik
- Magisk
- Vodafone mobilszolgáltatások
- Ezek a OnePlus 12 és 12R európai árai
- Poco F3 - a mindenes, de nem mindenkinek
Hirdetés
-
Összemoshatja a Google és a Magic Leap a valódi és a digitális világokat
it Együttműködésbe kezdett a Google és a Magic Leap nevű AR-startup.
-
Csak 2025-ben érkezik a Little Nightmares III
gp A sokak által várt folytatás sajnos nem fog idén megjelenni, kicsit tovább kell rá várnunk.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
Jester01
veterán
válasz skylaner #1148 üzenetére
Viszont nincs benne hossz korlátozás ezért használata erősen ellenjavalt (buffer overrun). Helyette általában az fgets ajánlott, de vigyázat, az viszont eltárolja a sorvég jelet is. Jelen esetben azonban teljesen felesleges sorokat olvasni, mivel a feladat karakter-orientált.
Jester
-
Gyuri16
senior tag
válasz skylaner #1158 üzenetére
makrot definialtal. ezt a c preprocessora feldolgozza, es a fordito mar nem latja hogy ott mi volt eredetileg, tehat addigra mar be van helyettesitve a makro teste, nincs fuggvenyhivas
wiki: [link]
gcc doksi: [link]mod: sokaig kinlodtam ezzel a bonyolult esszevel, megeloztek
[ Szerkesztve ]
Nem vagyok egoista, csak uborkagyalu!
-
Jester01
veterán
válasz skylaner #1161 üzenetére
Igen, a lezáró nulla csak akkor megy át, ha 14 byteot küldesz. Jelen esetben amúgy nem is kell lezárni: if (len == 13 && strncmp(msg, "download_over", 13) == 0) ....
Ja és a recv visszaadhat hibakódot (-1) vagy éppenséggel BUFF_SIZE értéket is és ezekben az esetekben a msg[len]='\0'; felettéb szerencsétlen lenne (de gondolom a hibakezelést csak innen a postból hagytad ki).
Jester
-
Jester01
veterán
válasz skylaner #1163 üzenetére
Hát a globális (illetve statikus) változók azok benne vannak a program fejlécében (objdump -h kimenetben data+bss). Lokális változók méreténél (ideértve a függvényargumentumokat is) nem tudom mit szeretnél tudni, esetleg a maximális verem méretet? Mivel ismereteim szerint linux alatt a verem nem csökken, ezért azt elvileg ki lehet nyomozni a futás végén. Például gdb-vel breakpoint az exit függvényre és a /proc/<pid>/maps fájlban a stack bejegyzésből.
[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz skylaner #1165 üzenetére
A valgrindban van egy "massif" eszköz is, az nem jó?
#-----------
snapshot=64
#-----------
time=124348
mem_heap_B=8
mem_heap_extra_B=8
mem_stacks_B=1008
heap_tree=detailed
n1: 8 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
n0: 8 in 1 place, below massif's threshold (01.00%)[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz skylaner #3958 üzenetére
1. A main visszatérési típusa int.
2. A string literálok típusa const char*.
3. Mivel a függvényed nem módosítja a stringet, oda is const char* ajánlott (különben az előző pont miatt nem tudod beadni a literált).
4. Karakterek kiírására putchar és társai valók.
5. Optimalizációs okokból az osztás általában kerülendő ha máshogy is meg lehet oldani.
6. Nyelveket nem keverjük (a függvényed szoveg_tordelo de a paraméter char_num), lehetőség szerint csak az angolt használjuk.Jester
-
Jester01
veterán
válasz skylaner #3972 üzenetére
A megjegyzéseket azért tettem, mert a topikot kezdők is olvassák akiknek esetleg hasznos lehet.
Amúgy mi a gond a printf("%c",c)-vel?
Működni működik, csak fölöslegesen küzd szegény gép a %c formátumstring feldolgozásával és még leírni is hosszabb Egyébként gcc van annyira okos, hogy kicseréli putchar hívásra, tehát ezesetben futásidőben már nincs hátránya (azon túl, hogy esetleg meglepődsz, hová lett a printf hívás).
Jester
-
PumpkinSeed
addikt
válasz skylaner #4023 üzenetére
Ez volt a legjobb ötlete, ugyanis nem szabadott kulcsot használni, és az kapott 5-öst akinek nem lehetett rájönni az algoritmusára.
Délután még megpróbálkozok máshogy is megcsinálni.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
-
dabadab
titán
válasz skylaner #4202 üzenetére
Mivel defaultban ugyis aligned az egesz, igy aztan abszolut semmit nem takaritasz meg azzal, hogy chart hasznalsz, csak egy plusz korlatot vezetsz be, ami aztan a kesobbiekben problemassa valhat (ugyanez vonatkozik az unsigned-ra is).
Es ha mar kapcsos zarojelek: igazabol erdemes mindig kirakni oket, szemleltetem.
Kiindulasi allapot:
for(i=0;i<n;i++)
if (palyak[i]==0)
{
nemsi_index[a]=i;
a++;
}Aztan az ember debuggol:
for(i=0;i<n;i++)
DEBUG("qweqwe");
if (palyak[i]==0)
{
nemsi_index[a]=i;
a++;
}Es maris kesz a katasztrofa, amihez raadasul az IDE-k boldogan asszisztalnak (true story ).
[ Szerkesztve ]
DRM is theft
-
buherton
őstag
válasz skylaner #4226 üzenetére
Mert ha elfelejtesz lezáró nullát tenni a string végére, akkor a strlen a világ végére is el tud menni.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
dabadab
titán
válasz skylaner #4230 üzenetére
"Dehát ez nem az strlen hibája."
De. Nem veletlenul talaltak ki az strnlen()-t.
"Most azért ne használjak egy már megírt fgv-t mert lehet, hogy hibás paraméterrel hívom meg?"
Igen, foleg ilyen esetekben, ahol a parameter jo esellyel nem magabol a programbol, hanem inputbol szarmazik, mivel ezzel hatalmas kaput nyitasz a buffer overflow exploitoknak.
"Tessék gondoskodni arról, hogy helyes paramétert adunk át a fgv-nek."
Hat, ha 100%-ra meg tudsz eskudni arra, hogy az strlen csak es kizarolag rendesen null-terminated stringet kap (es ha barhol, barmikor, barki megvaltoztat valamit a programban, ami miatt ez majd nem all fenn, akkor abban a pillanatban lecsereled), akkor csinald, de nekem joval egyszerubbnek tunik az strnlen() hasznalata.
[ Szerkesztve ]
DRM is theft
-
buherton
őstag
válasz skylaner #4230 üzenetére
A fejlesztőt védeni kell az ilyenektől, mert ha meg van a lehetőség a bakira, akkor a fejlesztő élni fog vele, és fog ilyen hibát véteni. Ahogy lehet látni az error exceptionokon, és rengeteg memory leak-en, és nem véletlenül retteg mindenki az optimazációs szint lépéstől , mert ilyenkor jobban összébb csúsznak a memóriában a dolgok, és igen hatékonyan eltudja rejteni a memória túl írásokat. A memcpy-nál meg tudod adni a méretet.
Nálunk új függvényeket csináltak erre, amivel biztosítva van, hogy a string mindig nullával végződik, így egy rakat hiba lehetősétől mentjük meg magunkat, de ettől függetlenül a hossz miatt még mindig vannak elírások akaratlanul is. Egy ilyen memória elírásnak a megkeresési ideje lehet 5 perctől 1 hétig terjedő idő, mert nálunk az OS nem árul el sokat, arról hogy hol történt a probléma.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
addikt
válasz skylaner #4269 üzenetére
Köszi, jogos.
Megnéztem egy régebbi példát, és annak mintájára külön függvénnyel fűztem a lista elejére.
Most így néz ki a működő verzió:
...
while(!feof(fp)){
fgets(temp, 256, fp);
sscanf(temp, "%d %[^\t] %[^\t] %[^\t] %[^\t] %[^\t] %c", &szint, &tempk, &tempa, &tempb, &tempc, &tempd, &valasz);
lista=elejere(lista, szint, tempk, tempa, tempb, tempc, tempd, valasz);
}
}
...
Kerdes* elejere(Kerdes *lista, int szint, char* tempk, char* tempa, char* tempb, char* tempc, char* tempd, char valasz){
Kerdes *uj;
uj=(Kerdes*) malloc(sizeof(Kerdes));
uj->szint=szint;
uj->ker=(char*) malloc((strlen(tempk)+1)*sizeof(char));
strcpy(uj->ker,tempk);
uj->a=(char*) malloc((strlen(tempa)+1)*sizeof(char));
strcpy(uj->a,tempa);
uj->b=(char*) malloc((strlen(tempb)+1)*sizeof(char));
strcpy(uj->b,tempb);
uj->c=(char*) malloc((strlen(tempc)+1)*sizeof(char));
strcpy(uj->c,tempc);
uj->d=(char*) malloc((strlen(tempd)+1)*sizeof(char));
strcpy(uj->d,tempd);
uj->valasz=valasz;
uj->kov=lista;
return uj;
}Most fgets-szel beolvasok egy sort, aztán sscanf-fel meg tabulátoronként darabolom és aztán rakom új listaelembe.
A listának meg nem is kellett volna helyet foglalni, mert az csak egy pointer..
Még egyszer kösz a segítséget mindenkinek! -
Peter789
senior tag
válasz skylaner #4280 üzenetére
Köszi, ez volt amit kerestem...
Közben felmerült egy másik kérdés is: van elegánsabb/gyorsabb megoldás több fájl egyidejű törlésére, mint a system("rm valami*") ? Vagy ki kell listázni, szűrni és egyesével törölni? A platformfüggőség nem katasztrófa, lévén hogy ez a program kizárólag openwrt-n fog futni és a fejlesztés is ubuntun zajlik, viszont az erőforrásigényt jó lenne minimalizálni amennyire lehet...
----------------------------------------------------------------------------------------------------------------- AquAgorA ...Pál apostol nyomában: http://fleettracker.eu/index.php/component/aquagora
-
kingabo
őstag
válasz skylaner #5252 üzenetére
Jaja. Nekem clipper kódot kellett portolnom igaz C#-ra. Fv első sora if akármi, az endif x ezer sorral lejjebb. Képtelenség volt átlátni, hogy mit csinál. Ha a működés fel lett volna osztva további fk-re, akkor szépen látszott volna minden lépés, hogy mit is csinál a cucc. (pl kérd le az adatokat, szűrd le, számolj velük, generálj exportokat, mentsd a változásokat)
Ráadásul, ha ügyesen bontad szét a működést és jó fv neket adsz igen nagy mértékben le lehet csökkenteni a kommentek mennyiségét. Nem kell kiírni, hogy most ezt csinálom azt csinálom, mert az fv nevéből látszik. A sokkal fontosabb, hogy miért csinálom kommentek (ami a sok komment között elveszik) pedig szem előtt lesznek, keresés nélkül is.
A C#-os region-okra egyre több helyen tekintenek rosszként. Github-on pl több helyen is írták, hogy egyáltalán ne legyen a kódban... Mellesleg amikor egy rakat kódot összefogsz egy régióba, azt akár ahogy van ki is rakhatod egy fv-be. És késöbb, ha bele kell nyúlnod könnyebben találod meg, könnyebb módosítani, sőt még a többi x helyre se kell a fixet copy-paste-elni, mert mindenhonnan fv-t hívsz.
Persze One-Man-Army esetén úgy dolgozol, ahogy jól esik, de ha másokkal kell együtt dolgozni, vagy más kódját kapod meg, amit először meg akarnál érteni, akkor (legalábbis számomra) mindenképpen hasznos, ha fv-kba szét van robbantva a kód és átlátható, mintha azt sem tudod az 1000 sorban hol is vagy éppen.
Sztem.[ Szerkesztve ]
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Steam topic
- Épített vízhűtés (nem kompakt) topic
- Computex 2024: Itt az új ROG Ally
- Futás, futópályák
- Megjelenési dátumot kapott a Tomb Raider animációs sorozat
- Anglia - élmények, tapasztalatok
- Autós topik
- Mibe tegyem a megtakarításaimat?
- Autós topik látogatók beszélgetős, offolós topikja
- Skull and Bones - Egy hétig ingyen játszhatunk vele
- További aktív témák...
- HP Laptop 15-fd051ne - ÚJ - 15,6" FullHD IPS notebook - Core i5-1335U, 8GB, 512SSD, Win11
- Brother DCP-L2532DW wifis, multifunkciós lézernyomtató
- HP Pavilion x360 14-ek Convertible - ÚJ - 14" TOUCH notebook - i5-1235U, 16GB, 512SSD, Win11
- HP Spectre x360 16-aa0775ng - ÚJ - 16"-os OLED notebook - Intel U7 155H
- Apple 96W USB-C hálózati adapter / töltő
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs