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

[Jan-Benedict Glaw]

On Thu, 2005-11-24 10:37:43 +0100, Oliver Bandel <oliver at first.in-berlin.de> wrote:
> 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.

Der GCC warnt, wenn eine Variable benutzt wird, ohne, daß sie vorher
initialisiert ist. (Vielleicht geht das aber ins Leere, wenn diese
nicht-initialisierte Variable an weitere Funktionen übergeben wird.)

> 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.

Ich versuche aber auch, schlank zu programmieren...

> > > (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.

Mit Crash meine ich SIGSEGV, jähes Ende des Programm-Lebens,
vielleicht noch ein core dump zum Abschied, und dann ist finito.

Ein totes Programm ist mir deutlich lieber, als eines, daß erst noch
die Daten hächselt...

> 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.

/* = 0 */

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

So kann man das auch sehen...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20051124/e403b0f6/attachment.sig>