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
*/