Alloc A
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (letzte Änderung) (Korrektur, Autor, Normalansicht)

Verändert: 146c146,147

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

Ist es rechtlich OK, hier Dokumente die (c) SCO sind zu veröffentlichen?

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.

KategorieAssembler
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 13. Februar 2006 14:26 (diff))
Suchbegriff: gesucht wird
im Titel
im Text