Re: Implementierung von malloc und free unter FreeBSD

On Mon, Sep 13, 2004 at 11:54:06AM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > On Fri, Sep 10, 2004 at 06:20:01PM +0200, Oliver Fromme wrote:
> > > Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > > > On Fri, Sep 10, 2004 at 03:27:44PM +0200, Oliver Boris Fischer wrote:
> > > > > Vielen Dank für Eure Antworten. Meine heutige Erfahrung bestätigt mich
> > > > > darin, Variablen und auch Speicher immer erst explizit und sei es mit
> > > > > char* v = NULL;
> > > >
> > > > Das macht man (unter C) sowieso - man sollte Variablen immer irgendwie
> > > > initalisieren und wenn man Speicher freigibt, dann haben anschließend
> > > > die Pointer darauf gefälligst auf NULL zu zeigen.
> > >
> > > Globale Variablen (bss) werden automatisch mit Nullen ini-
> > > tialisiert.
> >
> > Klar - aber Pointer auf malloc space benutzt man meistens als Stack
> > Variablen oder Bestandteil von dynamisch allocierten structures.
>
> Natürlich, das bestreite ich auch nicht. Ist sogar wün-
> schenswert.
>
> > Globale Pointer sind eher selten die richtige Wahl.
>
> Laß mich das ein wenig verschärfen:
> Globnale Variablen sind eigentlich nie die richtige Wahl.

Mit einem extren kleinem Stack ohne malloc kann das durchaus die
einzige Wahl sein.
Man programmiert ja schließlich in C nicht nur auf Megabyte Kisten.

> > Insgesammt benutzt man globale Variablen vorwiegend dann wenn man den
> > malloc/free Overhead vermeiden will und Platz auf dem Stack sparen
> > muss.
>
> Globale Variablen benutzt man (so zeigt die Praxis) über-
> wiegend dann, wenn man nicht strukturiert programmieren
> kann.

Ja, wobei das nicht unbedingt die Schuld des Programmierers sein muss,
sondern die Hardware bisweilen auch verantwortlich sein kann.

> > > Dynamische Variablen (auf dem Stack) werden nicht initiali-
> > > siert, daher sollte es dort der Programmierer explizit tun.
> > > Vor allem, da der gcc ziemlich lausig darin ist, festzu-
> > > stellen, ob eine Variable uninitialisiert verwendet wurde
> > > oder nicht.
> >
> > Zum Glück ist gcc3 da deutlich besser geworden -
>
> Ein C-Compiler kann prinzipbedingt nicht verläßlich zu
> prüfen, ob eine Variable uninitialisiert verwendet werden
> könnte. Er kann nur mehr oder weniger gut raten.

Das ist wohl wahr, denoch sind die meisten Treffer nützlich.

> > die meisten vergessen
> > nur leider diese Features zu aktivieren :(
>
> Ich schalte es absichtlich aus, weil es zu völlig hirnlosen
> Warnings führt. Genau wie dieses behämmerte Un-Feature,
> per Default Warnings auszuspucken, wenn man bestimmte GNU-
> Style-Guides nicht einhält (z.B. bei »if (x = 5)«, oder
> wenn man in geschachtelten ifs die geschweiften Klammern
> wegläßt u.ä.). Ich halte das für gcc-Bugs.

Das sind Kleinigkeiten mit denen ich bisweilen gut leben kann.

> > > Letztlich ist es natürlich ein Design-Mangel der Program-
> > > miersprache C.
> >
> > C ist eine Sprache, die für maschinennahes Programmieren spezialisiert
> > ist und für diesen Zweck ist es absolut kein Mangel, sondern ein
> > Vorteil.
>
> Äh? Was genau bezeichnest Du da als Vorteil?

Wenn ich eine Hardware mit 128Byte RAM habe brauche ich einfach die
Kontrolle über den Speicher.
Ein Sandkasten für die »besseren« Programmiersprachen ist da einfach
nicht drin.

> C ist heutzutage einfach völlig überholt. Für die meisten
> Applikationen, die heute noch in C (oder C++) geschrieben
> werden, sollte man besser eine Hochsprache verwenden, die
> es nicht so einfach macht, Bugs zu produzieren.

C ist bestenfalls in anbetracht des heutigen Gigabyte Wahns überholt.
Wenn dein Kühlschrank aber zukünftig in was anderem als C oder
Assembler programmiert werden soll, dann wird der letzlich auch spürbar
teurer - und wird letzlich auch mehr Strom brauchen.
Solche Anwendungen sind immer öfters anzutreffen.

> C ist einer der Hauptgründe, warum heutige Software so vie-
> le Bugs enthält.

Sicherlich hilft C wenig um derartige Fehler zu vermeiden, aber die
meisten Fehler in C Programmen liegen daran dass viele Programme von
unerfahrenen Programmieren geschrieben wurden, die in jeder Sprache
ihre Fallen finden würden.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message