man-pages/man3/alloca.3

153 lines
4.9 KiB
Groff
Raw Normal View History

2004-11-03 13:51:07 +00:00
.\" Copyright (c) 1980, 1991 Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)alloca.3 5.1 (Berkeley) 5/2/91
.\"
.\" Converted Mon Nov 29 11:05:55 1993 by Rik Faith <faith@cs.unc.edu>
.\" Modified Tue Oct 22 23:41:56 1996 by Eric S. Raymond <esr@thyrsus.com>
.\" Modified 2002-07-17, aeb
.\" 2008-01-24, mtk:
.\" Various rewrites and additions (notes on longjmp() and SIGSEGV).
.\" Weaken warning against use of alloca() (as per Debian bug 461100).
2004-11-03 13:51:07 +00:00
.\"
.TH ALLOCA 3 2008-01-24 "GNU" "Linux Programmer's Manual"
2004-11-03 13:51:07 +00:00
.SH NAME
2008-01-24 08:27:15 +00:00
alloca \- allocate memory that is automatically freed
2004-11-03 13:51:07 +00:00
.SH SYNOPSIS
.B #include <alloca.h>
.sp
.BI "void *alloca(size_t " size );
.SH DESCRIPTION
The
.BR alloca ()
2004-11-03 13:51:07 +00:00
function allocates
.I size
bytes of space in the stack frame of the caller.
This temporary space is
2004-11-03 13:51:07 +00:00
automatically freed when the function that called
.BR alloca ()
2004-11-03 13:51:07 +00:00
returns to its caller.
.SH "RETURN VALUE"
The
.BR alloca ()
2004-11-03 13:51:07 +00:00
function returns a pointer to the beginning of the allocated space.
If the allocation causes stack overflow, program behavior is undefined.
2004-11-03 13:51:07 +00:00
.SH "CONFORMING TO"
This function is not in POSIX.1-2001.
2004-11-03 13:51:07 +00:00
There is evidence that the
.BR 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.
.SH NOTES
The
.BR alloca ()
function is machine- and compiler-dependent.
For certain applications,
its use can improve efficiency compared to the use of
2008-03-05 11:30:11 +00:00
.BR malloc (3)
plus
.BR free (3).
In certain cases,
it can also simplify memory deallocation in applications that use
.BR longjmp (3)
or
.BR siglongjmp (3).
Otherwise, its use is discouraged.
Because the space allocated by
.BR alloca ()
is allocated within the stack frame,
that space is automatically freed if the function return
is jumped over by a call to
.BR longjmp (3)
or
.BR siglongjmp (3).
Do not attempt to
.BR free (3)
space allocated by
.BR alloca ()!
intro.1, time.1, _syscall.2, accept.2, brk.2, capget.2, faccessat.2, futimesat.2, gethostname.2, intro.2, ioprio_set.2, kill.2, madvise.2, mlock.2, mount.2, msgget.2, perf_event_open.2, poll.2, readv.2, sched_rr_get_interval.2, sched_setscheduler.2, select.2, select_tut.2, shmget.2, stat.2, timer_create.2, ustat.2, vfork.2, wait.2, alloca.3, atexit.3, catopen.3, crypt.3, dbopen.3, fenv.3, fopen.3, getaddrinfo_a.3, gethostbyname.3, getutent.3, intro.3, login.3, mallopt.3, queue.3, regex.3, sigpause.3, sigsetops.3, stdio.3, strftime.3, strptime.3, sysconf.3, ttyslot.3, undocumented.3, cciss.4, console_codes.4, hpsa.4, initrd.4, intro.4, rtc.4, st.4, tty_ioctl.4, wavelan.4, acct.5, charmap.5, dir_colors.5, hosts.5, intro.5, termcap.5, utmp.5, intro.6, armscii-8.7, boot.7, bootparam.7, capabilities.7, cpuset.7, credentials.7, ddp.7, epoll.7, glob.7, intro.7, ip.7, ipv6.7, iso_8859-1.7, iso_8859-10.7, iso_8859-11.7, iso_8859-13.7, iso_8859-14.7, iso_8859-15.7, iso_8859-16.7, iso_8859-2.7, iso_8859-3.7, iso_8859-4.7, iso_8859-5.7, iso_8859-6.7, iso_8859-7.7, iso_8859-8.7, iso_8859-9.7, koi8-r.7, koi8-u.7, man-pages.7, man.7, math_error.7, netlink.7, numa.7, packet.7, path_resolution.7, pipe.7, pthreads.7, raw.7, rtnetlink.7, signal.7, socket.7, spufs.7, svipc.7, tcp.7, time.7, udp.7, udplite.7, unicode.7, unix.7, uri.7, utf-8.7, x25.7, intro.8: Global fix: use consistent capitalization in .SS headings Capitalization in .SS sections across pages (and sometimes even within a single page) is wildly inconsistent. Make it consistent. Capitalize first word in heading, but otherwise use lower case, except where English usage (e.g., proper nouns) or programming language requirements (e.g., identifier names) dictate otherwise. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2013-02-24 14:08:38 +00:00
.SS Notes on the GNU version
2004-11-03 13:51:07 +00:00
Normally,
.BR gcc (1)
2004-11-03 13:51:07 +00:00
translates calls to
.BR alloca ()
with inlined code.
This is not done when either the
.IR "\-ansi" ,
.IR "\-std=c89" ,
.IR "\-std=c99" ,
or the
.IR "\-fno\-builtin"
option is given
(and the header
.I <alloca.h>
is not included).
But beware!
By default the glibc version of
2004-11-03 13:51:07 +00:00
.I <stdlib.h>
includes
.I <alloca.h>
2007-05-16 04:42:32 +00:00
and that contains the line:
.nf
#define alloca(size) __builtin_alloca (size)
2007-05-16 04:42:32 +00:00
.fi
2004-11-03 13:51:07 +00:00
with messy consequences if one has a private version of this function.
.LP
The fact that the code is inlined means that it is impossible
to take the address of this function, or to change its behavior
2004-11-03 13:51:07 +00:00
by linking with a different library.
.LP
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.
.SH BUGS
There is no error indication if the stack frame cannot be extended.
(However, after a failed allocation, the program is likely to receive a
.B SIGSEGV
signal if it attempts to access the unallocated space.)
2004-11-03 13:51:07 +00:00
On many systems
.BR alloca ()
2004-11-03 13:51:07 +00:00
cannot be used inside the list of arguments of a function call, because
the stack space reserved by
.BR alloca ()
2004-11-03 13:51:07 +00:00
would appear on the stack in the middle of the space for the
function arguments.
.SH "SEE ALSO"
.BR brk (2),
.BR longjmp (3),
.BR malloc (3)