This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
label differences doc update
- To: gcc-patches at gcc dot gnu dot org
- Subject: label differences doc update
- From: Richard Henderson <rth at cygnus dot com>
- Date: Fri, 30 Jul 1999 18:26:23 -0700
Index: extend.texi
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/extend.texi,v
retrieving revision 1.27
diff -c -p -d -r1.27 extend.texi
*** extend.texi 1999/04/14 05:34:34 1.27
--- extend.texi 1999/07/31 01:25:47
*************** Another use of label values is in an int
*** 295,304 ****
The labels within the interpreter function can be stored in the
threaded code for super-fast dispatching.
! You can use this mechanism to jump to code in a different function. If
! you do that, totally unpredictable things will happen. The best way to
avoid this is to store the label address only in automatic variables and
never pass it as an argument.
@node Nested Functions
@section Nested Functions
--- 295,316 ----
The labels within the interpreter function can be stored in the
threaded code for super-fast dispatching.
! You may not use this mechanism to jump to code in a different function.
! If you do that, totally unpredictable things will happen. The best way to
avoid this is to store the label address only in automatic variables and
never pass it as an argument.
+
+ An alternate way to write the above example is
+
+ @example
+ static const int array[] = @{ &&foo - &&foo, &&bar - &&foo, &&hack - &&foo @};
+ goto *(&&foo + array[i]);
+ @end example
+
+ @noindent
+ This is more friendly to code living in shared libraries, as it reduces
+ the number of dynamic relocations that are needed, and by consequence,
+ allows the data to be read-only.
@node Nested Functions
@section Nested Functions