Új hozzászólás Aktív témák
-
skylaner
senior tag
válasz stranger28 #4193 üzenetére
Szia!
Én annyit tennék hozzá, hogy mivel 0-tól 100-ig fogsz számokat tárolni így felesleges memória pazarlás int-et használni.
unsigned char *palyak;Illetve a többi változó is lehetne char/unsigned char.
[ Szerkesztve ]
-
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
-
dabadab
titán
válasz Jester01 #4205 üzenetére
Kenytelen vagyok visszakozni: megtakaritana, mivel itt csupa char lenne. Ha amugy egy csomo intje meg pointere lenne, es akoze rakna be egy-egy chart, akkor nem lenne megtakaritas, mert ott azoknak a 4 / 8 byte-os alignmentje bekavarna, de ha tenyleg mindenki char, akkor nincs ilyen gond.
DRM is theft
-
alapz@j
tag
Én mindig ugyanabba a sorba rakom a nyitó kapcsost, még függvény definíciónál is
int main(void) {
return 0;
}a típusjelölésre teszem a csillagot, mert olvashatóbb
char* nothing(char* string) {
return string;
}Ja, és egy sorra soha nem használok kapcsost:
if (..)
for (...)
printf("Hit me!\n"); -
Jester01
veterán
válasz alapz@j #4207 üzenetére
A kapcsos zárójel elhelyezése ízlés dolga, de az egy soros dolgok köré is erősen ajánlott kitenni őket, mivel ahogy arra dababab már rámutatott, később könnyen hibához vezethet.
Jester
-
válasz Jester01 #4209 üzenetére
Meg az ilyenek elkerülése végett:
#define PRINT_TEXT printf("foo"); printf("bar");
if(...)
PRINT_TEXTvagy
if(...)
if(...)
elseKihez is tartozik az else?
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... !!!
-
aAron_
őstag
megint egy hülye kérdésem lenne a codeblocks-al kapcsolatban, valaki meg tudná mondani, hogy lehet kikapcsolni a kommentek helyesírás (?) ellenőrzését? most mindent szép piros hullámos vonallal aláhúz nekem, elég idegesítő hosszú távon, mert nehezíti a gyors olvasást.
nem is értem, legutóbb semmit nem kellett ilyenekkel vackolnom, most meg a angol hotkeyektől kezdve minden nevetséges hülyeséggel szívok.
What is your ikigai?
-
daneel92
tag
sziasztok!
restellem, hogy ilyenhez kell folyamodnom, de tudnátok segíteni programozás háziban? holnap van a leadási határidő, és marhára nem értem a témát. két feladatból áll. az egyik ez:
Írjon egy programot amely, létrehoz egy két dimenziós tömböt (mátrixot), tölti a mátrixot véletlen értékű elemekkel, és írja ki a tömböt klasszikus mátrix formában, utána még egyszer írja ki a mátrixot de a sorokból csinál oszlopokat és az oszlopokból csinál sorokat. Programja kalkuláljon a 3. sor és a 4. oszlop elemeinek az összegét.
a másik ez:
Írjon egy programot amely, megoldja egy lineáris egyenletrendszert.
Igazából magát a mátrix témakört nem értem, hogy az olyanokat, mint invertálás hogyan tudom megvalósítani c-ben.Asrock B450 Pro4, AMD Ryzen 7 2700 @3.2GHz, Sapphire Radeon RX 5700 XT Pulse 8GB, Chieftec 600W
-
neil_mullen
aktív tag
Sziasztok!
A problémám az lenne hogy c-ben elakadtam az fscanf használatánál. Egy file-ba irtam 138 db számot, 'k' a kezdőérték, 0.25-tal csökkentve. Ezt float-ban irtam ki (fprintf) és float-ban is olvastam vissza (fscanf). És hát a baj az hogy az első számot még jól olvassa be
de a többinél "levág" az elejéből. Előre is köszi a segítséget.#include <stdio.h>
#include <stdlib.h>int main()
{
FILE *file1;
char a='k';
int c=0;
double b, d;
file1=fopen("adat.txt","w+");
if(file1==NULL) printf("hiba");
while(c<138)
{
b=(double)(a);
d=b-(c*0.25);
fprintf(file1,"%f",d);
c++;
}
fclose(file1);FILE *file2;
file2=fopen("adat.txt","r");
if(file1==NULL) printf("hiba");
char f;
float e=0;
while(!feof(file2))
{
fscanf(file2,"%f",&e);
printf("%f\n",e);
//f=(char)(e/1);
}
fclose(file2);
}Privát üzenetre illik válaszolni!!!
-
Bobrooney
senior tag
válasz neil_mullen #4213 üzenetére
rakj sortörést az fprintf-be
fprintf(file1,"%f\n",d);Mellesleg minket suliban óva intettek az fscanf használatától. fgets-el kérd be majd sscanf-el jobban le tudod kezelni. // Nekünk így mondták és látok is benne rációt.
[ Szerkesztve ]
-
v2izzy
tag
Hello!
Megkérdezhetném, hogy mi a gond a realloc függvénnyel? Miért nem tanácsos használni?
Mert az egyetemem úgy tűnik eléggé ellenzi.
Azt értem, hogy nem szerencsés sokszor meghívni (tehát pl minden új elemre egy tömbnél újraméretezni), mert ugye lehet hogy az egész területet át kell másolja. De pont olyan feladatot adtak ki, ahol le van írva, hogy minden új elemre növelni kell a tömb méretetét.
Így most kb. ugyanazt írom meg mint a realloc, csak éppen azt sem tudom megnézni, hogy van-e a memóriában hely a lefoglalt terület előtt...http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger
-
Szia!
Szerintem azért, mert sokan elfelejtik, hogy a realloc-nak a visszatérési értékét kell odaadni a pointernek. Ezt sokan elfelejtik, ugyanis ha új helyre másolja, akkor értelemszerűen a pointernek is változnia kell. Személy szerint nem tudom, hogy mi más probléma lenne ebből. Igaz, nálunk tiltott mindennemű dinamikus memória foglalás, mert ha használnánk, akkor a rendszer előbb utóbb lefagyna.
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... !!!
-
Karma
félisten
válasz buherton #4217 üzenetére
"Szerintem azért, mert sokan elfelejtik, hogy a realloc-nak a visszatérési értékét kell odaadni a pointernek."
Pont ezt nem szabad csinálni azelőtt, hogy megnézné az ember hogy NULL-t adott-e vissza a realloc – mert ha igen, akkor elveszted az eredeti memóriaterületet.
Ettől függetlenül se a realloctól, se a calloctól való félelmet nem értem az oktatásban, bár lehet hogy anno megmagyarázták; én meg elfelejtettem.
“All nothings are not equal.”
-
v2izzy
tag
Én sem értem. Ha valakit érdekel itt van a slide, ahol felhívják a figyelmet erre. Leginkább a gondom amúgy az volt, hogy egy beadandónál nem fogadta el az oldal a programomat, mert szerepelt benne a realloc szó.
Még ezekkel kapcsolatban lenne olyan kérdésem, hogy ha meghívom realloc-ot, hogy kisebb memóriaterületet foglaljon, akkor levágja a lefoglalt területet? Ha igen, akkor mindig vagy ez függhet más dolgoktól?
http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger
-
Karma
félisten
Gyanús hogy azért nem fogadta el, mert azt akarta, hogy kézzel implementáld le ugyanezt. A helyszínen kellett volna kifejtetni vele az ítéletét.
Az oldalon lévő szöveg is csak annyit mond, hogy lassú lehet – de ez éppúgy igaz arra is, ha kézzel mallocolsz nagyobb területet, átmásolod memcpyval, és felszabadítod az előzőt.
A kulcsmondat igazából ez: "Ne írjunk olyan programokat, amelyek gyakran méreteznek át tömböket!"
A szabvány alapján nincs arra garancia, hogy ha kisebbre reallocolsz, akkor nem fogja mozgatni a memóriát. Mindenképpen le kell kezelned a visszatérési értéket helyesen, azaz nézni a NULL választ, és nemNULL esetben kicserélni az előzőt siker esetén; ha fel-, ha leméretezel.
“All nothings are not equal.”
-
Áh értem most már.
(#4219) alapz@j: Nem op.rendszer függő, hanem architektúra. Az általunk használt ARM nem támogatja az MPU-t, így ha dinamikusan foglalsz memóriát, majd szabadítasz fel, akkor egy idő után teljesen széttöredezik a memória tábla, és lefagy az egész. De ha támogatná sem lehetne használni, mert automotive.
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... !!!
-
Dave-11
tag
Van az alábbi kódom:
char *c = malloc(sizeof (char) * 5);
Tehát lényegében ezzel létrehoztam egy karaktertömböt. Ennek az értékét akartam megadni, majd kiíratni az alábbi módokon, de nem jött össze:
Két módszer az értékek megadására:
1. c = "Szia";
2. *c = "Szia";
Az 1. megoldást gondoltam hogy nem jó, mert ugye pointernek hülyeség értéket adni, az ugye csak a memóriacímet tudja tárolni.
A 2.-ban már bíztam, mert ugye a * operátorral visszamutatok a karaktertömbre, és úgy próbáltam megadni az értékét (mint hagyományos módon: char c[] = "Szia";)
Aztán ha esetleg működött is az előző, a printf()-el nem tudtam kiíratni sehogy.
Próbáltam így is: printf("%s",c); meg így is: printf("%s",*c); de mindkét próbálkozásnál kifagyott a program.
Szerintetek mi lehet a hiba?:D Semmi :D
-
válasz Dave-11 #4223 üzenetére
Ezzel már letárolod a memóriában a tömböt: "Szia!", erről nyugodtan lehet kérni pointert, ahogy függvény argumentumként szokták is csinálni, de csak megkötésekkel.
1 év PERL után tértem vissza a C-re, és nagyon felidegesítettem magam, hogy mi a hét szentségért nem hajlandó benyelni a fordító ezt: char foo[10]; foo = "bar";
strncpy, és strncmp függvényeket használd, és figyelj mindig a \0 karakterre. Az strlen-t pedig kerüld amennyire tudod.
(#4224) Korcsii: arra a MasterCard való .
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... !!!
-
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... !!!
-
válasz Bobrooney #4228 üzenetére
Igaz, de nem mindenhol elérhető a printf , vagyis éppen elérhető, de önmagában nem csinál semmit. AMúgy futottam már ilyenbe, és ha nincs rá debug akkor tud érdekes dolgokat csinálni.
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... !!!
-
skylaner
senior tag
válasz buherton #4227 üzenetére
Dehát ez nem az strlen hibája.
Most azért ne használjak egy már megírt fgv-t mert lehet, hogy hibás paraméterrel hívom meg?
A fejlesztő feladata és felelőssége, hogy helyesen használja a fgv-ket.
Most akkor a memcpy se használjuk mert lehet, hogy a source adatszerkezet kevesebb byte-ból áll mint amit a 3. paraméterben megadtunk?Szerintem nem jó amit mondasz.
Tessék gondoskodni arról, hogy helyes paramétert adunk át a fgv-nek.
Az strlen() teljesen jól van megírva. -
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
-
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... !!!
-
tototos
őstag
Sziasztok!
Egy kis segítwséget szeretnék kérni.
Adott egy maximum 8 bájtos tömböm, amibe maximum 16 bites változókat szeretnék beszúrni bizonyos bitpozíciókra. A bitpozíciók a nyagságból adódóan 0-tól 63-ig lehetnek számozva. Az első megoldásom az lett volna hogy a tömb helyett használok egy 64 bites változót de ennek a kezelését nem támogatja az eszköz. Tudnátok erre a problémára valamilyen optimális megoldást mondani?
Köszönöm
-
dabadab
titán
válasz tototos #4233 üzenetére
mennyire jo megoldasod van?
en valami ilyesmit csinalnek:
uint16 array[4];
void insert(uint16 value, uint address)
{
uint pos;
uint shift;
pos = address >> 4;
shift = address & 0x0f;
array[pos] = value << shift;
array[++pos] = value >> ( 0x0f - shift);
}Mondjuk ezt erosen endian-fuggo, szoval inkabb at kellene irni unit8-as tombre, de a lenyeg ez, meg kinullazza a byte-ok szelet, szoval ott valami maszkolni meg orozni kell, ha ez baj.
[ Szerkesztve ]
DRM is theft
-
tototos
őstag
válasz dabadab #4234 üzenetére
Köszi.
Hát most végül működik 64 bites változóval de nem tudom mennyire optimális.
Ez az amikor kiveszek egy tömbböl elemeketuint8_t LINReceiveBuffer[8];
LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameValue = 0;
for (Index = 0;Index < ResponseDataByteIndex-1;Index++)
{
LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameValue += (LINReceiveBuffer[Index+1] << ((LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameDataLength - 1 - Index)*8));
}Ezzel rakom be:
if (ResponseDataByteIndex < LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameDataLength)
{
DataCheck = (uint8_t)(LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameValue >> (LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameDataLength - 1 - ResponseDataByteIndex)*8);
LINChecksumBuffer[ResponseDataByteIndex+1] = DataCheck;
USART_SendData(USART6,DataCheck);
ResponseDataByteIndex++;
} -
Jester01
veterán
válasz dabadab #4234 üzenetére
Továbbá még azt is vizsgálni kellene, hogy 16 bites határon van-e éppen, mert akkor elég 1 tömb elemet írni (ez ugye akkor fontos ha az utolsó elemről van szó, mert akkor a következő már túlírja a tömböt).
Ja és nem 0x0f - shift hanem 0x10 - shift
[ Szerkesztve ]
Jester
-
tototos
őstag
válasz Jester01 #4238 üzenetére
Köszi.
Melyik a jobb megoldás ha veszek egy 64 bites változót, és ebbe rakom be az adatokat, majd ezt bájtokra bontva elküldöm, vagy az ha a tömbbe rakom be a fenti módszerrel az adatokat és a tömböt küldöm ki?
Ugyanezt kell visszafele is, tehát van egy uint8_t tömb[8] tömb, amiből ki kell nyernem az adat pozíciótól az adott hosszú adatokat.@dabadab: Bájtosával kell kiküldenem az adatokat, és úgy is kapom őket. Tehát vagy alapból bájt tömbben tárolom őket, vagy a 64 bites változómat darabolom bájtokra, valamint vételnél visszafele.
[ Szerkesztve ]
-
tototos
őstag
Ha egy 64 bites változóban szeretném átírni a biteket az 5. bittől kezdődően 7 bit hosszan akkor hogy kellene kimaszkolni, hogy a többi bit ne változzon? Nem jut eszembe semmi értelmes általános megoldás. AZ offszet és a hossz változhat.
Köszi
-
Jester01
veterán
-
Karma
félisten
válasz tototos #4241 üzenetére
Ha törölni akarod azt a szakaszt, akkor ÉSelned kell egy olyan számmal, ami a kívánt bitszakaszon 0, körülötte 1. Ha beállítani, akkor meg VAGYolnod kellegy olyannal, ami a szakaszon 1, mindenhol máshol 0.
Pl. 01010101 & 11100011 = 01000001,
Ill. 01010101 | 00011100 = 01011101Persze az előbbi megoldás teljesebb, mert a maszkot is megcsinálja és konkrét értéket is tud
[ Szerkesztve ]
“All nothings are not equal.”
-
tototos
őstag
Sziaszto!
Egy érdekes problémával állok szembe. C-ben szeretnék stringeket darabolni. Ez egyenlőre nem tűnik nagy feladatnak, van egy függvényem ami szépen darabolja a dolgokat. A gond ott kezdődik, hogy amikor fel akarok szabadítani a feldarabolt részeknek allokált területet akkor egyszer a free függvény váratlan hibát generál és a mikrovezérlőm elmegy egy végtelen ciklusba.
EZ lenne a daraboló függvény:
char** str_split(char* a_str, const char* a_delim)
{
char** result = 0;
size_t count = 0;
char* tmp = a_str;
char* last_comma = 0;
size_t index;
/* Count how many elements will be extracted. */
while (*tmp)
{
for (index = 0; index < strlen(a_delim); ++index)
{
if (*(a_delim+index) == *tmp)
{
count++;
last_comma = tmp;
}
}
tmp++;
}
/* Add space for trailing token. */
count += last_comma < (a_str + strlen(a_str) - 1);
/* Add space for terminating null string so caller
knows where the list of returned strings ends. */
count++;
result = malloc(sizeof(char*) * count);
if (result)
{
size_t idx = 0;
char* token = strtok(a_str, a_delim);
while (token)
{
assert(idx < count);
*(result + idx++) = strdup(token);
token = strtok(0, a_delim);
}
//assert(idx == count - 1);
*(result + idx) = 0;
}
return result;
}Ez pedig egy része a kódnak:
tokens = str_split(line, ",;");
if (tokens)
{
LINScheduleTable[frameIndex].Frame.SignalIDs_lda16[signalIndex] = atoi(*tokens);
LINScheduleTable[frameIndex].Frame.SignalOffsets_lda8[signalIndex] = atoi(*(tokens+1));
for (i = 0; *(tokens + i); i++)
{
free(*(tokens + i));
}
free(tokens);
}Az érdekesség, hogy ez a részlet meghívódik kb 25-ször, és 26. lépésnél száll el.
Láttok valami hatalmas hibát a kódban?Köszi
-
válasz tototos #4245 üzenetére
Milyen mikrokontrollerről van szó? Van benne MPU? Ha nincs, akkor a malloc/free használata teljes öngyilkosság, és borítékolható a fagyás. Ha auto változóba tárolod le a stringet, akkor azt stackre rakja, ha jól rémlik.
MPU nélküli MCU-kban is lehet dinamikus memóriákat foglalni, de ahhoz neked kell a kezedbe venned a memória menedzsmentet. A mi projektünkben a kommunikációs driver pont így működik.
[ Szerkesztve ]
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... !!!
-
válasz tototos #4247 üzenetére
Akkor meg van válasz a kérdésedre. A malloc/calloc/realloc/free tabu.
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... !!!
-
tototos
őstag
válasz buherton #4248 üzenetére
Köszi Nem tudtam hogy ennyire tiltott. Azt tudtam hogy beágyazott környezetben kb halál, de most szükségem lenne rá sajnos.
Van az oprendszerben saját heap kezelő. Sajnos ez is kiakad egy ponton. Amikor fel akarom szabadítani a char** változót.
Megnéznétek a kódot, hogy biztosan jól használom a dolgokat? Sajnos valami programozási hibára gyanakszom.[ Szerkesztve ]
-
válasz tototos #4249 üzenetére
Az a baj a dinamikus memória használattal, hogy MPU nélkül nincs ki töredezettségmentesítse a memória táblát, és így előbb utóbb jön a hard fault exception, és jöhet a fej vakarás, hogy most ez mi a bánat volt, mert az RTOS-ek nem arról híresek, hogy szájbarágósan leírja, hogy mi történt (tapasztalat). Azt szokták csinálni, hogy előre lefoglalnak x memóriát, és arra írnak egy vezérlőt, ami karbantartja azt a területet, és ha kell akkor neked pointert, de ennek a technikai részletét nem ismerem. De mondom használj auto változót, vagy hát ha valaki másnak van jobb ötlete.
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... !!!
Ú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!