Dynamisches Ändern der Größe von Arrays

Nein.

Beim Einsatz auf kleinen µC wäre das auch keine gute Idee, da auf diesem 
Weg mit einem Schlag alle Sicherheitsprobleme, die mit dynamischer 
Speicherverwaltung verbunden sind, in die Anwendung eingebaut würden.

Es bleibt nur, die maximal benötige Größe zu bestimmen und den Speicher 
fest zu reservieren.

Bert:

> Ein "alloc" und Co. kann ich nicht verwenden, da nicht unterstützt.

Einzelne Umgebungen (lies: GCC-basierend) unterstützen eine dynamische 
Allokation auf dem Stack. Nennt sich alloca(). In diesem Fall ist es 
einfach und die Nebenwirkungen sind überschaubar.

> Für einfache Variablen oder Instanzen kann man sich malloc und free
> selber per makro implementieren.

Das ist reine Augenwischerei:

Macros werden noch vor der eigentlichen Übersetzung vom Preprozesser 
abgearbeitet. Daraus folgt: Es handelt sich um reine 
Textersetzungsoperationen; Macroparameter werden textuell im Macrorumpf 
substituiert.

Ein Macro kann keine Heapverwaltung implementieren. Was man mit einem 
Macro malloc erreichen kann, das kann man auch direkt dort hinschreiben, 
wo der Macro expandiert würde: eine Variablendefinition.

free als Macro? das geht ganz einfach nicht...

Was spricht denn gegen

1

void

2

foo(int len)

3

{

4

    char array[len];

5

    /* something very usefull */

6

}

...wenn sonst keine dynamische Speicherverwaltung verfügbar ist?
Sicher gibt's gerade dabei Stolperstellen, aber bis er darauf gekommen 
ist, dass es zu 99% auch ohne geht, sollte das doch weiterhelfen!?

Dagegen spricht erstens, dass dies erst mit C99 möglich ist, mit C89 
noch nicht. Und viele Compiler im Controller-Umfeld tun sich mit C99 
etwas schwer.

Zweitens wird Bert wohl genau dies probiert haben, der Meldung nach zu 
schliessen.

Andreas Kaiser wrote:
> Dagegen spricht erstens, dass dies erst mit C99 möglich ist, mit C89
> noch nicht. Und viele Compiler im Controller-Umfeld tun sich mit C99
> etwas schwer.
>

Aha, ich muss also in einem GCC-Forum davon ausgehen, dass es sich um 
einen Compiler handelt, der die Features eines GCC-Compilers nicht 
unterstützt?

> Zweitens wird Bert wohl genau dies probiert haben, der Meldung nach zu
> schliessen.

Hat Dir das die Glaskugel verraten?
Meine hat mir gesagt, dass er eben 'static' vor 'char' verwendet hat ;-)

1

void

2

foo(int len)

3

{

4

  static char array[len];

5

}

1

main.c: In function 'foo':

2

main.c:15: error: storage size of 'array' isn't constant

Danke an Bert, dass er das aufgeklärt hat!

> Aha, ich muss also in einem GCC-Forum davon ausgehen, dass es sich um
> einen Compiler handelt, der die Features eines GCC-Compilers nicht
> unterstützt?

Sein Text:

> Ein "alloc" und Co. kann ich nicht verwenden, da nicht unterstützt.

sprach gegen GCC. Denn GCC kann alloca und die avr-libc hat malloc/free.

Andreas Kaiser wrote:
>> Aha, ich muss also in einem GCC-Forum davon ausgehen, dass es sich um
>> einen Compiler handelt, der die Features eines GCC-Compilers nicht
>> unterstützt?
>
> Sein Text:
>
>> Ein "alloc" und Co. kann ich nicht verwenden, da nicht unterstützt.
>
> sprach gegen GCC. Denn GCC kann alloca und die avr-libc hat malloc/free.

Das spricht lediglich gegen die verwendete libc, aber sei's d'rum.

>> Denn GCC kann alloca
>
> Wenn die libc es unterstützt.

Wenn du ein
 #define alloca(size) __builtin_alloca(size)
als libc ansiehst, ja. Bis auf den Namen ist die Funktionalität von 
alloca() bei GCC allerdings ziemlich zwangsläufig Sache des Compilers, 
nicht der Library. Auch bei manchen anderen Compilern.

Rolf Magnus wrote:

> avr? Wo steht denn was von avr?

Ok. Gibt es ein leidlich gängiges GCC Paket ohne malloc?

Andreas Kaiser wrote:

> Bis auf den Namen ist die Funktionalität von
> alloca() bei GCC allerdings ziemlich zwangsläufig Sache des Compilers,
> nicht der Library. Auch bei manchen anderen Compilern.

Das ist eigentlich zwangsläufig der Fall.  Die Bibliothek hat ja keinen
Einfluss auf den Funktionsepilog, den der Compiler generiert, genau
der muss aber bei alloc() das Aufräumen organisieren.  Das kann also
nur im Compiler passieren.

> Das ist eigentlich zwangsläufig der Fall.  Die Bibliothek hat ja keinen
> Einfluss auf den Funktionsepilog, den der Compiler generiert, genau
> der muss aber bei alloc() das Aufräumen organisieren.  Das kann also
> nur im Compiler passieren.

Wenn ein Compiler stets mit getrenntem Stack- und Frame-Pointer 
arbeitet, geht es auch ohne Compiler-Support. So war alloca() 
ursprünglich entstanden. Nur ist das mittlerweile aus der Mode gekommen.

Walter Bright (Digital Mars) beispielsweise implementiert alloca() als 
Lib-Funktion, scheint es aber im Compiler doch irgendwie zu kennen, denn 
es erzwingt den vollen Stack-Frame.