This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

label differences doc update



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]