Re: Implementierung von malloc und free unter FreeBSD

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.

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

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

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

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

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 einer der Hauptgründe, warum heutige Software so vie-
le Bugs enthält.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"File names are infinite in length, where infinity is set to 255 characters."
        -- Peter Collinson, "The Unix File System"
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message