X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=glib%2Fgalloca.h;h=483a6c805acfe9045a7b9b540bf82c2150fd3a86;hb=35eaf037bdfca985abf5d349e7355f1d2ed9c77b;hp=1ecdf65c042caf66c0421f9bdcbb541087ff286a;hpb=c9affa778e14e7dc44221fa678963e09df744f32;p=platform%2Fupstream%2Fglib.git diff --git a/glib/galloca.h b/glib/galloca.h index 1ecdf65..483a6c8 100644 --- a/glib/galloca.h +++ b/glib/galloca.h @@ -12,9 +12,7 @@ * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public - * License along with this library; if not, write to the - * Free Software Foundation, Inc., 59 Temple Place - Suite 330, - * Boston, MA 02111-1307, USA. + * License along with this library; if not, see . */ /* @@ -24,16 +22,18 @@ * GLib at ftp://ftp.gtk.org/pub/gtk/. */ +#ifndef __G_ALLOCA_H__ +#define __G_ALLOCA_H__ + #if !defined (__GLIB_H_INSIDE__) && !defined (GLIB_COMPILATION) #error "Only can be included directly." #endif -#ifndef __G_ALLOCA_H__ -#define __G_ALLOCA_H__ - #include -#ifdef __GNUC__ +#if defined(__BIONIC__) && defined (GLIB_HAVE_ALLOCA_H) +# include +#elif defined(__GNUC__) /* GCC does the right thing */ # undef alloca # define alloca(size) __builtin_alloca (size) @@ -65,33 +65,26 @@ G_END_DECLS * stack frame is cleaned up. This macro essentially just wraps the alloca() * function present on most UNIX variants. * Thus it provides the same advantages and pitfalls as alloca(): - * - * - * + alloca() is very fast, as on most systems it's implemented by just adjusting - * the stack pointer register. - * - * - * + It doesn't cause any memory fragmentation, within its scope, separate alloca() - * blocks just build up and are released together at function end. - * - * - * - Allocation sizes have to fit into the current stack frame. For instance in a - * threaded environment on Linux, the per-thread stack size is limited to 2 Megabytes, - * so be sparse with alloca() uses. - * - * - * - Allocation failure due to insufficient stack space is not indicated with a %NULL - * return like e.g. with malloc(). Instead, most systems probably handle it the same - * way as out of stack space situations from infinite function recursion, i.e. - * with a segmentation fault. - * - * - * - Special care has to be taken when mixing alloca() with GNU C variable sized arrays. - * Stack space allocated with alloca() in the same scope as a variable sized array - * will be freed together with the variable sized array upon exit of that scope, and - * not upon exit of the enclosing function scope. - * - * + * + * - alloca() is very fast, as on most systems it's implemented by just adjusting + * the stack pointer register. + * + * - It doesn't cause any memory fragmentation, within its scope, separate alloca() + * blocks just build up and are released together at function end. + * + * - Allocation sizes have to fit into the current stack frame. For instance in a + * threaded environment on Linux, the per-thread stack size is limited to 2 Megabytes, + * so be sparse with alloca() uses. + * + * - Allocation failure due to insufficient stack space is not indicated with a %NULL + * return like e.g. with malloc(). Instead, most systems probably handle it the same + * way as out of stack space situations from infinite function recursion, i.e. + * with a segmentation fault. + * + * - Special care has to be taken when mixing alloca() with GNU C variable sized arrays. + * Stack space allocated with alloca() in the same scope as a variable sized array + * will be freed together with the variable sized array upon exit of that scope, and + * not upon exit of the enclosing function scope. * * Returns: space for @size bytes, allocated on the stack */