Skriva ut array, varför inte bara på ett sätt?

[Nerre]

Vi verkar ju vara överens om att i följande fall fylls de sista 10 bytesen med nollor:

Kod: Markera allt

char my_global_array[20] = "123456789";
static char my_private_array[20] = "123456789";

char* my_other_function(void)
{
  static char my_static_array[20] = "123456789";
  return my_static_array;
}

Njäe, det läggs väl till en NULL efter en sträng (d.v.s. nåt som står mellan två "). Inte flera?

[bearing]

Ja, en null, och sen även 10 stycken till null i det här fallet eftersom att array är 20 bytes, d.v.s de sista tio är inte initierade i koden, och får då värdet noll i det här fallet. Med terminering av strängen blir det alltså 11 st.

[Nerre]

En oinitierad lokal variabel är odefinierad.

Detta eftersom den oftast ligger på stacken (eller är nåt för tillfället ledigt register).

En global/static variabel fylls ut med nollor om den inte är helt initierad.

Ja, varje C-program har en INIT (minns inte om den heter exakt så) som körs före main(), där globala variabler initieras och där läggs dessa på HEAP har jag för mig.

En lokal/automatic variabel som inte är initierad kan ha vilket värde som helst.

Precis som en vanlig lokal variabel ligger den väl oftast på stacken?

En lokal/automatic variabel som är delvis initierad borde också fyllas med nollor. Standarden(erna) är inte jättetydlig(a) på den punkten, men gcc fyller i alla fall på med nollor i det fallet också.

Det är intressant att titta på assemblerkoden som en C-kompilator skapar, man lär sig mycket från den. Olika kompilatorer gör nog olika med sånt som inte är definierat. Men generellt så tar det ju tid att initiera en variabel, så man vill väl inte hålla på och initiera den mer än nödvändigt.

[snigelen]

Detta eftersom den oftast ligger på stacken (eller är nåt för tillfället ledigt register).

Det spelar ingen roll var variabeln ligger, kompilatorn får följa standarden i alla fall. (Men det är nog anledningen till att lokala, oinitierade variabler inte har något definierat värde.)
Annars håller jag med dig Nerre.

bearing: Vi är nog helt överens, bara lite otydligt om det var lokala variabler det handlade om eller ej.

[snigelen]

Ja, en null, och sen även 10 stycken till null i det här fallet eftersom att array är 20 bytes, d.v.s de sista tio är inte initierade i koden, och får då värdet noll i det här fallet. Med terminering av strängen blir det alltså 11 st.

Jupp, så är det.

[bearing]

Ja, varje C-program har en INIT (minns inte om den heter exakt så) som körs före main(), där globala variabler initieras och där läggs dessa på HEAP har jag för mig.

Var static och global läggs i minnet är nog olika. Beror bl.a. på hur man mappar minnet, o.s.v.

Det som TomasL är inne på är att man inte kan vara säker på att static blir noll på microkontrollers, därför att vissa rensar bort denna initkod, bl.a. för att spara uppstartstid. Det får till följd att alla static och global i hela projektet är oinitierade, oavsett vad som står i koden. Därför måste man hantera static lite speciellt i dessa sammanhang. De som är static i c-filen kan t.ex. initieras i en speciell init-rutin. De som är statiska i en funktion kan man t.ex. hantera med en if-sats.

Jag har jobbat på ett ställe där man ville hålla koll på all kod i hela projektet, och inte använda några bibliotek eller annan färdig kod alls, vilket innebar att vi även skrev initieringskoden som körs innan main. Jag skrev hela den koden för en 32-bit MCU baserad på PowerPC en gång, vilket jag var ganska stolt över. Jag gjorde så att sekvensen började i assembler, gick över till C-efter ett tag, och när allt var klart, ja då anropade jag helt enkelt main.

[Nerre]

(Men det är nog anledningen till att lokala, oinitierade variabler inte har något definierat värde.)

Jo, det var det jag menade. När en funktion anropas så läggs ju returadressen på stacken och sen läggs lokala variabler oftast där (eftersom en funktion måste kunna vara rekursiv). Då vill man inte behöva loopa igenom hela variabelutrymmet och skriva över det, utan det som finnas där är det som fanns där tidigare.

Vissa lokala variabler kan läggas i register, men de pushas då till stacken innan nästa funktionsanrop, och popas vid retur.

[snigelen]

Det som TomasL är inne på är att man inte kan vara säker på att static blir noll på microkontrollers, därför att vissa rensar bort denna initkod, bl.a. för att spara uppstartstid.

Det spelar väl ingen som helst roll om det är microkontroller eller inte. Endera är det en C/C++-kompilator eller inte. Lämpligen bör man veta om man har en sådan, eller inte. Men visst, vill man köra på gissningar och vilda spekulationer så kan man väl göra det. Men då är man ute på en cykeltur...

[Nerre]

Jag har jobbat på ett ställe där man ville hålla koll på all kod i hela projektet, och inte använda några bibliotek eller annan färdig kod alls, vilket innebar att vi även skrev initieringskoden som körs innan main. Jag skrev hela den koden för en 32-bit MCU baserad på PowerPC en gång, vilket jag var ganska stolt över. Jag gjorde så att sekvensen började i assembler, gick över till C-efter ett tag, och när allt var klart, ja då anropade jag helt enkelt main.

Det är så man lär sig hur det fungerar:)

Jag lärde mig det när jag började pilla lite med AVR för en massa år sen och funderade på om jag skulle skriva i assembler eller C. provade att skriva en "blinka LED"-snutt i både assembler och C, och sen tweaka bägge (t.ex. ändra register i assemblerversionen) tills assemblerkoden blev i princip lika för bägge (i alla fall koden för main). (Det krävde dock att man slog av nästan all optimering på C-kompilatorn.)

Jag försökte också för många år sen lära mig hur man skriver en kompilator. Jag hade ett väldigt långsökt projekt där jag ville skapa Z80-kod på en PC. I grunden handlade det om att jag ville få igång ett hemmaskrivet operativsystem på min gamla SVI-328 (med "Super expander"). Jag hade idéer om hur jag skulle få till nåt som kunde liknas vid multitasking. Men jag ville ju inte sitta och koda på Spectravideon utan ville koda på PC:n och sen föra över (tänkte skriva en serieportsrutin manuellt på Spectravideon, för det hade jag gjort för ABC80 många år tidigare.)

Spectravideon finns kvar på vinden, men vet inte om den ens startar idag:)

[bearing]

Det som TomasL är inne på är att man inte kan vara säker på att static blir noll på microkontrollers, därför att vissa rensar bort denna initkod, bl.a. för att spara uppstartstid.

Det spelar väl ingen som helst roll om det är microkontroller eller inte. Endera är det en C/C++-kompilator eller inte. Lämpligen bör man veta om man har en sådan, eller inte. Men visst, vill man köra på gissningar och vilda spekulationer så kan man väl göra det. Men då är man ute på en cykeltur...

C-kompilatorn lägger all data som ska kopieras till SRAM (static, global, osv) i binärfilen, d.v.s det hamnar i FLASH-minnet efter flashning. Men för att den datan ska hamna i SRAM innan main körs måste funktionen som heter _init() eller liknande kopiera från FLASH till SRAM. Och det är alltså denna funktion som jag ersatte med egen kod på ett jobb jag hade. Dom gjorde så i alla projekt där. Och därför hade alla globala och static odefinierade värden i början av main, trots att vi använde en C-kompilator.

Om det var detta som TomasL syftade på, eller om han bara gissade, eller cyklade, eller spekulerade, det vet jag dock inte. =)

[snigelen]

Ja men herre/fru DEITY, väljer du att åsidosätta den kod kompilatorn genererar så väljer du det. Det har väl för 17 inget att göra med huruvida variabler blir initierade eller inte av en C/C++-kompilator.

[TomasL]

Om det var detta som TomasL syftade på, eller om han bara gissade, eller cyklade, eller spekulerade, det vet jag dock inte. =)

Nja, det handlar om god programmeringssed, att alltid i alla lägen initiera variabler oavsett om kompilatorn gör det eller inte.
Helt plötsligt springer man på en custom-gcc, eller någon annan kompilator där variabler inte initieras.
Även om det bör vara på ett specifikt sätt, så skall man aldrig utgå ifrån det.

Dessutom är det ju så att man skall hålla globala och statiska variabler till ett minimum.

[Nerre]

Ja det är ju mer än ett program som buggat ur för att programmeraren tagit för given att en variabel är noll eller "tom sträng" innan man stoppat nåt i den.

[bearing]

Ja men herre/fru DEITY, väljer du att åsidosätta den kod kompilatorn genererar så väljer du det. Det har väl för 17 inget att göra med huruvida variabler blir initierade eller inte av en C/C++-kompilator.

Nej det har du rätt i. Men jag tror som sagt inte att det är helt ovanligt att man inte litar på dessa saker, utan förutsätter att de inte fungerar. Iaf inte inom brancher som jobbar med maskiner/fordon styrda med hjälp av mikrocontrollers programmerade i C. Ifall någon pixel flimrar i ett PC-program får buggen inte lika stora konsekvenser.

Om man skriver säker realtidskod enligt standarden IEC 61508 eller ISO 26262 t.ex, och följer MISRA, gäller det att ha koll på koden som körs. Att lita på att någon open source-kompilator med tillhörande bibliotek genererar allt rätt så att inte maskinen löper amok och orsakar personskada, det vågar inte så många. Därför köper man inom denna branch ofta speciella kompilatorer som är certifierade. De är svindyra, och därför har små företag inte råd med dessa. Som alternativ kan företaget göra vad de kan med tillgängliga medel för att se till att programmet inte har buggar. Företaget jag jobbade på valde att använda en köpt kompilator, fast ocertifierad. Vi skrev sedan precis varenda kodrad i mjukvaran, för att inte få med ev. buggar i uppstartsrutiner eller mjukvarubibliotek från C-miljön.

Nu är jag/vi så klart ute i periferin och pratar här. Det är inte så relevant i den här tråden kanske, utan mer kuriosa. Eller man kanske ska säga "nördsnack". Den Arduino som tråden ursprungligen handlade om är trots allt en ATmega mikrocontroller som kör realtidsprogram, så helt utanför ämnet är det ju inte. De system som regleras av ovannämnda standarder är också mikrocontrollers som kör realtidsprogram.

[snigelen]

Men om du (TL) nu inte litar på att kompilatorn kan göra en av sina absolut enklaste uppgifter; att initiera variabler. Hur kan du då tro på att den verkligen tar tio varv i en loop, och inte elva, eller tjugosju?

Henry: Jag antar att du inte har något emot att tråden spårade ur till något helt annat?