GNU C - WinAVR v. ATMEL und Pointer bei ATMega128

[U. B. (ub007)]

Hallo !

Ein Kollege unserer Abteilung ist zu einer anderen Firma gewechselt und 
ich muss jetzt das Projekt übernehmen.
Wie ich damals am Rande mitbekommen habe lief es bei seinem Programm 
offensichtlich sehr schlecht. Ab und zu lief mal das Programm und beim 
nächsten mal stürzte alles ab. Und so gings immer wieder hin und her. 
Wie er mir sagte ist er fit in C und kam so gesehen frisch von der Uni 
und hat keine Programmiererfahrung.
Das Verhalten seines Programms wie er es mir erzählte ist merkwürdig. Es 
konnte auch sein dass es 3 mal ging und dann wieder kompleter Absturz. 
Es konnte nicht an der Hardware liegen, da er gerade deswegen eine neue 
Platine aufbaute - die aber die gleichen Effekte/Abstürze zeigte. Ich 
fragte ihn ob er mit Pointern arbeitet und er bestätigte es. Ich weiß 
dass dieses Verhalten des Programms typisch für Pointer ist, wenn man 
ein paar Dinge nicht beachtet. Ich habe die Unterlagen seines 
Source-Codes noch nicht erhalten aber bei der Besprechung konnte ich 
folgendes sehen - ich habe es hier etwas vereinfacht !

void main(void)
{
   int a=5;
   int *b;

    a = 3;
   *b = 2;
}

Prinzipiell ist gegen das obige Progrämmchen nichts einzuwenden. Ich bin 
aber der Meinung dass man bei Pointern vorsichtig sein muss (In seinem 
Programm wird der Pointer dazu verwendet um aus einer uSD-Karte 
Informationen über die FAT zu bekommen. Dazu wird der Funktion ein 
Pointer übergeben.)
Da das Programm aber sporadische Abstürze hat, bin ich der Meinung dass 
man Pointern zumindest eine Adresse, die nicht belegt ist, zuweisen 
muss, denn *b kann ja wirklich irgendwo im Adressraum hinzeigen. Solange 
man nun nichts in den Pointer schreibt - passiert auch nichts, nur wenn 
man z.B. eine Zuweisung alla *b=3 macht wird quasi der Inhalt auf den 
der Pointer zeigt überschrieben und das kann wie gesagt sonstwo sein. 
Mein Kollege sagte dem Chef das Fehler im GNU-C Compiler vorliegen. Ich 
habe zwar versucht meinen Chef vom Gegenteil zu überzeugen, aber ich 
habe eher den Eindruck seine Entscheidung ist gefallen.
Kann das jemand bestätigen ?

Gruß Uli

[abc (Gast)]

Ähh... So wie das deklariert ist ist b ein vagabundierender Pointer und 
*b=42 überschreibt irgendwo Daten.

[Uwe (Gast)]

Hallo,

anders ausgedrückt b ist keiner Variabel zugeordnet.

also b=&b wäre ein Weg, dann wäre die Speicherstellen gleich und es gilt 
(*b) == a

[Turbo J (Gast)]

Uwe schrieb:
> Hallo,
>
> anders ausgedrückt b ist keiner Variabel zugeordnet.
>
> also b=&b wäre ein Weg, dann wäre die Speicherstellen gleich und es gilt
> (*b) == a

Du meinst

b=&a;

[tom (Gast)]

uli,

wenn dein codebeispiel stimmt, hat dein kollege da grundlegend mist 
gebaut.

es liegt nicht am gcc sondern am user, die vorredner haben den 
irgendwohin (hängt vom zufälligen inhalt der RAM speicherzellen des 
pointers ab) zeigenden pointer ja schon erwähnt.

wird ein pointer nicht lokal, wie hier - sondern global oder static 
deklariert zeigt er in der regel dann auf adresse 0x0 und das kann dann 
je nach verwendetem uC (harvard oder von neumann architektur) und wie 
dann die speicherbereiche evtl. noch gemappt sind, dorthin zeigen und 
ein beschreiben des selbigen speicherbereiches führt zu undefiniertem 
verhalten des programmes (i.d.r.).


wenn dein chef das nicht blickt, hat er auch keine ahnung.


also, VOR jeder benutzung eines zeigers diesen bitteschön auf den 
gewollten speicher zeigen lassen !

char array[10];
char *ptr_to_array;

ptr_to_array = &array[0];

*ptr_to_array = 42;
ptr_to_array++;
*ptr_to_array = 7;

...

jetzt mit dem debugger mal schauen und in array[0] sollte 42 (die 
ultimative antwort) und in array[1] eine 7 drin sein.


gruss + das wars mit dem wort zum sonntach, tom.

[Karl H. (kbuchegg)]

> Mein Kollege sagte dem Chef das Fehler im GNU-C Compiler vorliegen.

Du kannst deinen CHef ja mal fragen ob er wirklich glaubt, dass in einem 
Compiler, der weltweit von Millionen Programmierern eingesetzt wird, in 
einem derartigen Grundlagenbereich, wie es Pointer nun mal darstellen, 
Fehler enthalten sind.

Klar, gibt es auch bei GCC Fehler. Aber die meisten werden innerhalb 
kürzester Zeit ausgemerzt. Eine breite Basis von Programmierern sorgt 
weltweit dafür, dass kaum etwas unentdeckt bleibt. Nicht umsonst gilt 
bei seltsamen Fehlern die Devise: Erst wenn 100% klar und von 2 oder 3 
erfahrenen Programmierern abgesegnet wurde, dass der Fehler nicht im 
Code oder in einem fehlerhaften C-Verständnis zu finden ist, werden 
Fehler im Compiler das erste mal ins Auge gefasst.

> Wie er mir sagte ist er fit in C und kam so gesehen frisch
> von der Uni und hat keine Programmiererfahrung.

In den meisten Fällen beißt sich das. Die Zeiten, in denen man Freaks 
von den Unis bekam, die wirklich gut drauf und fit sind, ist vorbei. 
Heutzutage kriegt man von den Unis in den meisten Fällen Absolventen, 
die gerade noch so lala programmieren bzw. Software designen und 
entwickeln können. Ein Uni Abschluss ist gerade im Bereich Software 
schon lange kein Garant mehr dafür, dass man Entwickler bekommt, die man 
problemlos in den Entwicklungsprozess integrieren kann. Ihnen fehlt es 
an Erfahrung und das nicht zu knapp. Mit 500 bis 1000 Zeilen Programmen 
hast du nun mal im industriellen Umfeld wenig bis gar nichts angefangen.

[U. B. (ub007)]

Hallo Karl-Heinz - hallo Tom !


Ganz genau !!! Yepp, das geht runter wie Öl.
So wie Du Tom es geschrieben hast, so mache ich das auch und habe noch 
nie Probleme gehabt. Die Programme laufen stabil !

Ich möchte euch allen dafür Danken !!!

Gruß Uli