tags 461100 fixed-upstream
thanks
(changes in upstream 2.77)
Vincent Lefevre wrote:
> Package: manpages-dev
> Version: 2.67-1
> Severity: normal
>
> The alloca(3) man page says:
>
> BUGS
> The alloca() function is machine and compiler dependent.
> On many systems its implementation is buggy. Its use is
> discouraged.
>
> The first sentence doesn't give more information than sections
> "CONFORMING TO" and "NOTES", and concerning the second sentence,
> Torbjorn Granlund says in the MPFR mailing-list[*]:
>
> That text is FUDish; I have never encountered any bugs with alloca on
> any of the many GMP target systems.
>
> So, this misleading paragraph should be removed.
While I don't think we can take one developer's experience as gospel
(though it would be useful to know the range of platforms that Torbjorn has
tested), I do agree that the warning in the existing text is a bit strong.
I removed the sentence containing "buggy", and relocated the rest under NOTES:
NOTES
The alloca() function is machine- and compiler-dependent.
Its use is discouraged.
Perhaps the two of you might still feel that this is a bit strong, but
before I make further changes, I'd be interested in specific details of
platforms that have been found to be problem free.
I also reworked various other parts of the page, so that it now reads as
shown below. The changes will be in upstream 2.77. Thanks for your report!
Cheers,
Michael
NAME
alloca - allocate memory that is automatically freed
SYNOPSIS
#include <alloca.h>
void *alloca(size_t size);
DESCRIPTION
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.
RETURN VALUE
The alloca() function returns a pointer to the beginning
of the allocated space. If the allocation causes stack
overflow, program behavior is undefined.
CONFORMING TO
This function is not in POSIX.1-2001.
There is evidence that the alloca() function appeared in
32V, PWB, PWB.2, 3BSD, and 4BSD. There is a man page for
it in 4.3BSD. Linux uses the GNU version.
NOTES
The alloca() function is machine- and compiler-dependent.
Its use is discouraged.
Because the space allocated by alloca() is allocated
within the stack frame, that space is automatically freed
if the function return is jumped over by a call to
longjmp(3) or siglongjmp(3).
Do not attempt to free(3) space allocated by alloca()!
Notes on the GNU Version
Normally, gcc(1) translates calls to alloca() with
inlined code. This is not done when either the -ansi,
-std=c89, -std=c99, or the -fno-builtin option is given
(and the header <alloca.h> is not included). But beware!
By default the glibc version of <stdlib.h> includes
<alloca.h> and that contains the line:
#define alloca(size) __builtin_alloca (size)
with messy consequences if one has a private version of
this function.
The fact that the code is inlined means that it is impos-
sible to take the address of this function, or to change
its behavior by linking with a different library.
The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack
overflow. Thus, there is no NULL error return.
BUGS
There is no error indication if the stack frame cannot be
extended. (However, after a failed allocation, the pro-
gram is likely to receive a SIGSEGV signal if it attempts
to access the unallocated space.)
On many systems alloca() cannot be used inside the list
of arguments of a function call, because the stack space
reserved by alloca() would appear on the stack in the
middle of the space for the function arguments.
SEE ALSO
brk(2), longjmp(3), malloc(3)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
