Die GNU manpage zu dem Thema hat folgenden Wortlaut: "The alloca function allocates size bytes of space in the stack frame of the caller. This temporary space is automatically freed when the function that called alloca returns to its caller." Da anzunehmen ist, dass diese manpage im GNU System schon wesentlich älter als Unixware 7.1.1 (1999) ist, ist die hier zitierte wahrscheinlich eh' aus ur-alt UNIX Code gestohlen. Das einzige Problem ist somit die inkorrekte Attribution durch SCO.

(BSD System Compatibility) alloca(3bsd) _________________________________________________________________ alloca -- (BSD) memory allocator Synopsis /usr/ucb/cc [flag . . . ] file . . . #include <alloca.h> char *alloca(int size); Description alloca allocates size bytes of space in the stack frame of the caller, and returns a pointer to the allocated block. This temporary space is automatically freed when the caller returns. Note: if the allocated block is beyond the current stack limit, the resulting behavior is undefined. References brk(2), csh(1), getrlimit(2), ld(1), malloc(3C), sigstack(3bsd), sigvec(3bsd) Stephenson, C.J., Fast Fits, in Proceedings of the ACM 9th Symposium on Operating Systems, SIGOPS Operating Systems Review, vol. 17, no. 5, October 1983 Core Wars, in Scientific American, May 1984 Notices alloca is machine-, compiler-, and most of all, system-dependent. Its use is strongly discouraged. _________________________________________________________________ 5 November 1999 © 1999 The Santa Cruz Operation, Inc. All rights reserved. UnixWare 7 Release 7.1.1 - 5 November 1999

Die Notiz (Notices) trifft auf alloca() als Library-Funktion zu, sie trifft nicht zu, wenn alloca() compiler-intern ist.
Lediglich die Portabilität ist dann eingeschränkt.

Folgende selbst entwickelte Funktion hatte es mir mal ermöglicht, den gcc2.8.1 zu kompilieren, mit einem Compiler, der alloca() nicht kennt: (Der Ersatz alloca.c mit malloc/free hatte zuvor nicht funktioniert!):

.text .globl alloca alloca: movl 4(%esp), %eax movl (%esp), %edx movl %eax, %ecx addl $15, %eax andl $0xfffffff0, %eax jz .Jret subl %eax, %esp movl %esp, %eax pushl %ecx pushl %edx .Jret: ret .align 8 .type alloca,@function .size alloca,.-alloca

Ausblick auf C99-Compiler:

Heute mit gcc:

int main(void) { extern int a; int i; char *c= alloca(a); // char c[a]; //C99-Lösung for (i=0; i<a; ++i) c[i]= 74; return (0); }

Zugehöriger Assembler:

.text .align 16 .globl main .type main,@function main: pushl %ebp movl %esp,%ebp pushl %ebx movl a,%edx movl %edx,%ebx leal 15(%edx),%eax andb $240,%al subl %eax,%esp movl %esp,%ecx xorl %eax,%eax cmpl %edx,%eax jge .L4 .align 4 .L6: movb $74,(%eax,%ecx) incl %eax cmpl %ebx,%eax jl .L6 .L4: xorl %eax,%eax movl -4(%ebp),%ebx movl %ebp,%esp popl %ebp ret .Lfe1: .size main,.Lfe1-main .ident "GCC: (GNU) 2.95.2 19991024 (release)"

--hs

Welchen praktischen Nutzen hat eine Funktion, die bei Speichermangel auf dem Stack ein undefiniertes Verhalten (d. h. meistens Programmabbruch) hat?

Welchen Nutzen hat der gcc, der das mit seiner internen alloca() genau so macht?
gcc benutzt so etwas in seinem eigenen Code zuhauf und stellt alloca() dem Programmierer zur Verfügung.
Welchen Nutzen hat die Sprache C, worin das seit C99 ebenfalls genau so gemacht wird, ohne Prüfung von Wertangabe und Stack-Ressourcen?

Die Sprache ISO C99 definiert keine Funktion namens alloca().

Richtig, C99 hat alloca fest in C eingebaut und nennt das VLA statt alloca.

Wenn man so argumentiert, muß man natürlich auch fragen: Welchen Nutzen haben lokale (Auto-)Variablen überhaupt? Wenn ich Speichermangel auf dem Stack habe, funktionieren die auch nicht mehr. Ob ich char "*c= alloca(74);" oder "char c[74];" schreibe, kommt platzmäßig auf dasselber heraus. Das ist IMHO ein immanentes problem jeder Programmierung... Daß ich keine 20MB an Speicher mit alloca allokieren kann, sollte klar sein.