[linux-l] do{ . } while (0) (was: Arrays in C)

[Oliver Bandel]

On Thu, Nov 24, 2005 at 08:05:24AM +0100, Jan-Benedict Glaw wrote:
> On Thu, 2005-11-24 00:43:56 +0100, Oliver Bandel <oliver at first.in-berlin.de> wrote:
> > Auch mache ich es normalerweise so, daß ich jeden Pointer, den ich
> > irgendwann mal im Laufe der Funktion benutze, gleich am Anfang
> > schon auf NULL setze. Dann ist er in gewisser Weise in einem
> > definierten Zustand und ich kann mit NULL-Tests immer abchecken,
> > was Sache ist. (Ich chekce auch immer alle Args auf NULL,
> > was manche inem paranoid erscheint - aber für gute/solide SW-Entwicklung
> > braucht man diesen gewissen paranoiden Mindest-Zustand ;-))
> 
> Hmmm... Das seh' ich anders. Wenn ein pointer dazu genutzt werden
> soll, ein Ergebnis entgegenzunehmen, warum sollte man ihn dann vorher
> nochmal initialisieren? Das bläht doch nur das DATA-Segment auf...

Weil man als Mensch auch mal Fehler macht und es auch mal vorkommen
kann, daß man in seinem Code mal etwas umbaut, und dann etwas übersieht.
Dann ist der Pointer ggf. nicht auf NULL initialisiert und ein NULL-Test
geht ins Leere, man hebelt dann also seine eigenen Sicherheitsmechanismen
aus.



> 
> > Falls man nämlich aus irgend einem Grunde mal eine Funktion, die
> > den ersten Zuweisungsakt zu jenem Pointer unternimmt, auskommentiert
> > oder irgendwie anders verbaselt, dann hat man definitiv
> > seine NULL drinne. :)
> 
> Wenn ich in einer Funktion was auskommentiere, gucke ich sie mir
> nochmal an :-)

Klar.
Und Du machst nie Fehler?
Schön für Dich. Das denken auch zig tausende andere Programmierer
von sich.
Ich brauche mir nur anschauen, wie viele BufferOferflow und
andere Bugs dauernd in SW-Projekten angezeigt werden und
weiß dann, daß das nicht stimmt.
Du magst da ja die große Ausnahme sein. ;-)

Ich weiß von mir jedenfalls, daß ich Fehler mache
und "paranoider" Programmierstil hilft, diese frühzeitig
aufzudecken.

> 
> > (Und wenn andere Funktionen das immer schön abtesten, weiß man
> >  dann, wenn es an irgend einer Stelle statt eines Crashes eine
> >  Fehlermeldung gibt, daß da eine NULL erschien, die nicht erwartet wurde,
> >  wie weit Fehler in einer Source reichen können... "Das Weltall, unbekannte Tiefen...")
> 
> Wenn schon, dann richtig!  In so einer Situation (wo eine _erwartete_
> Zuweisung aufmal weg ist) würde ich einen Crash / assert erwarten.

Hoffentlich keinen Crash in dem Sinne, wie ich ihn verstehe: Wilde-Sau-Spiel
durch Pointer-Zugriff auf irgendwelchen unbekannten Müll sonstwo im
RAM-Universum.


> 
> > Das selbe gilt natürlich auch für andere Variablen:
> > int immer auf 0 definieren (außer ein anderer Wert
> > macht mehr Sinn), auch wenn man es anscheinend soweiso nochmal
> > zuweist... usw.
> 
> *schuettel*

Tja, man hat dann einen definitiven Startpunkt. Das ist IMMER gut,
wenn man definierte Startbedingungen hat.

In funktionalen Sprachen geht es garnicht anders.
Da hat man immer eine feste Bindung von Name und Value.

let x = 9

bzw.

let a = 3and b = 4 in a * b


da ist es durch die Sprache vorgegeben, daß die Values immer
definiert sind.

In C kann irendwelcher Müll drin stehen.

Und selbst wenn C in bestimmten Fällen Defaults vorgibt
und Werte vor-definiert mag es u.U. sinnvoll sein, diese
nochmals explizit hin zu schreiben (z.B. bei static),
enfach deshalb, daß man es explizit nochmal sieht, wenn man
in den Code guckt.

Alles, was explizit im Code steht ist schon mal Selbstdokumentation
und schafft Klarheit.

Ciao,
   Oliver