aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorMike Pall <mike>2022-06-23 09:10:09 +0200
committerMike Pall <mike>2022-06-23 09:10:09 +0200
commit2e98c3d0644fc0c265844908f43b7e4526dd819c (patch)
treeb9116c671f4268be7776696abdb189de4be5cf43 /doc
parent7dc3850e78493eed1e85fa7bc0b96068ae7fb9f4 (diff)
downloadluajit-2e98c3d0644fc0c265844908f43b7e4526dd819c.tar.gz
luajit-2e98c3d0644fc0c265844908f43b7e4526dd819c.tar.bz2
luajit-2e98c3d0644fc0c265844908f43b7e4526dd819c.zip
Grammar and spell check.
Diffstat (limited to 'doc')
-rw-r--r--doc/ext_c_api.html4
-rw-r--r--doc/ext_ffi.html14
-rw-r--r--doc/ext_ffi_api.html10
-rw-r--r--doc/ext_ffi_semantics.html58
-rw-r--r--doc/ext_ffi_tutorial.html24
-rw-r--r--doc/ext_jit.html4
-rw-r--r--doc/extensions.html8
-rw-r--r--doc/faq.html6
-rw-r--r--doc/install.html8
-rw-r--r--doc/running.html4
-rw-r--r--doc/status.html4
11 files changed, 72 insertions, 72 deletions
diff --git a/doc/ext_c_api.html b/doc/ext_c_api.html
index a5d02473..b328047a 100644
--- a/doc/ext_c_api.html
+++ b/doc/ext_c_api.html
@@ -103,7 +103,7 @@ Turn the whole JIT compiler on or off or flush the whole cache of compiled code.
103This sets the mode for the function at the stack index <tt>idx</tt> or 103This sets the mode for the function at the stack index <tt>idx</tt> or
104the parent of the calling function (<tt>idx = 0</tt>). It either 104the parent of the calling function (<tt>idx = 0</tt>). It either
105enables JIT compilation for a function, disables it and flushes any 105enables JIT compilation for a function, disables it and flushes any
106already compiled code or only flushes already compiled code. This 106already compiled code, or only flushes already compiled code. This
107applies recursively to all sub-functions of the function with 107applies recursively to all sub-functions of the function with
108<tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with 108<tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with
109<tt>LUAJIT_MODE_ALLSUBFUNC</tt>. 109<tt>LUAJIT_MODE_ALLSUBFUNC</tt>.
@@ -122,7 +122,7 @@ traces which link to it.
122This mode defines a wrapper function for calls to C functions. If 122This mode defines a wrapper function for calls to C functions. If
123called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt> 123called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt>
124must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper 124must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper
125function. From now on all C functions are called through the wrapper 125function. From now on, all C functions are called through the wrapper
126function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned 126function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned
127off and all C functions are directly called. 127off and all C functions are directly called.
128</p> 128</p>
diff --git a/doc/ext_ffi.html b/doc/ext_ffi.html
index 7a87ca65..04b78d98 100644
--- a/doc/ext_ffi.html
+++ b/doc/ext_ffi.html
@@ -153,7 +153,7 @@ call the binding function. Phew!
153<h2 id="cdata">Motivating Example: Using C Data Structures</h2> 153<h2 id="cdata">Motivating Example: Using C Data Structures</h2>
154<p> 154<p>
155The FFI library allows you to create and access C&nbsp;data 155The FFI library allows you to create and access C&nbsp;data
156structures. Of course the main use for this is for interfacing with 156structures. Of course, the main use for this is for interfacing with
157C&nbsp;functions. But they can be used stand-alone, too. 157C&nbsp;functions. But they can be used stand-alone, too.
158</p> 158</p>
159<p> 159<p>
@@ -165,7 +165,7 @@ implemented with a big table holding lots of tiny tables. This imposes
165both a substantial memory overhead as well as a performance overhead. 165both a substantial memory overhead as well as a performance overhead.
166</p> 166</p>
167<p> 167<p>
168Here's a sketch of a library that operates on color images plus a 168Here's a sketch of a library that operates on color images, plus a
169simple benchmark. First, the plain Lua version: 169simple benchmark. First, the plain Lua version:
170</p> 170</p>
171<pre class="code"> 171<pre class="code">
@@ -180,7 +180,7 @@ local function image_ramp_green(n)
180 return img 180 return img
181end 181end
182 182
183local function image_to_grey(img, n) 183local function image_to_gray(img, n)
184 for i=1,n do 184 for i=1,n do
185 local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue) 185 local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue)
186 img[i].red = y; img[i].green = y; img[i].blue = y 186 img[i].red = y; img[i].green = y; img[i].blue = y
@@ -190,14 +190,14 @@ end
190local N = 400*400 190local N = 400*400
191local img = image_ramp_green(N) 191local img = image_ramp_green(N)
192for i=1,1000 do 192for i=1,1000 do
193 image_to_grey(img, N) 193 image_to_gray(img, N)
194end 194end
195</pre> 195</pre>
196<p> 196<p>
197This creates a table with 160.000 pixels, each of which is a table 197This creates a table with 160.000 pixels, each of which is a table
198holding four number values in the range of 0-255. First an image with 198holding four number values in the range of 0-255. First, an image with
199a green ramp is created (1D for simplicity), then the image is 199a green ramp is created (1D for simplicity), then the image is
200converted to greyscale 1000 times. Yes, that's silly, but I was in 200converted to grayscale 1000 times. Yes, that's silly, but I was in
201need of a simple example ... 201need of a simple example ...
202</p> 202</p>
203<p> 203<p>
@@ -304,7 +304,7 @@ be more compact and faster. This is certainly true (by a factor of
304~1.7x). Switching to a struct-of-arrays would help, too. 304~1.7x). Switching to a struct-of-arrays would help, too.
305</p> 305</p>
306<p style="font-size: 8pt;"> 306<p style="font-size: 8pt;">
307However the resulting code would be less idiomatic and rather 307However, the resulting code would be less idiomatic and rather
308error-prone. And it still doesn't get even close to the performance of 308error-prone. And it still doesn't get even close to the performance of
309the FFI version of the code. Also, high-level data structures cannot 309the FFI version of the code. Also, high-level data structures cannot
310be easily passed to other C&nbsp;functions, especially I/O functions, 310be easily passed to other C&nbsp;functions, especially I/O functions,
diff --git a/doc/ext_ffi_api.html b/doc/ext_ffi_api.html
index 687b85c5..962db6dc 100644
--- a/doc/ext_ffi_api.html
+++ b/doc/ext_ffi_api.html
@@ -117,7 +117,7 @@ separated by semicolons. The trailing semicolon for a single
117declaration may be omitted. 117declaration may be omitted.
118</p> 118</p>
119<p> 119<p>
120Please note that external symbols are only <em>declared</em>, but they 120Please note, that external symbols are only <em>declared</em>, but they
121are <em>not bound</em> to any specific address, yet. Binding is 121are <em>not bound</em> to any specific address, yet. Binding is
122achieved with C&nbsp;library namespaces (see below). 122achieved with C&nbsp;library namespaces (see below).
123</p> 123</p>
@@ -205,7 +205,7 @@ parse the cdecl only once and get its ctype with
205<tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly. 205<tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly.
206</p> 206</p>
207<p style="font-size: 8pt;"> 207<p style="font-size: 8pt;">
208Please note that an anonymous <tt>struct</tt> declaration implicitly 208Please note, that an anonymous <tt>struct</tt> declaration implicitly
209creates a new and distinguished ctype every time you use it for 209creates a new and distinguished ctype every time you use it for
210<tt>ffi.new()</tt>. This is probably <b>not</b> what you want, 210<tt>ffi.new()</tt>. This is probably <b>not</b> what you want,
211especially if you create more than one cdata object. Different anonymous 211especially if you create more than one cdata object. Different anonymous
@@ -252,12 +252,12 @@ afterwards. Neither the contents of the <tt>metatable</tt> nor the
252contents of an <tt>__index</tt> table (if any) may be modified 252contents of an <tt>__index</tt> table (if any) may be modified
253afterwards. The associated metatable automatically applies to all uses 253afterwards. The associated metatable automatically applies to all uses
254of this type, no matter how the objects are created or where they 254of this type, no matter how the objects are created or where they
255originate from. Note that pre-defined operations on types have 255originate from. Note that predefined operations on types have
256precedence (e.g. declared field names cannot be overridden). 256precedence (e.g. declared field names cannot be overridden).
257</p> 257</p>
258<p> 258<p>
259All standard Lua metamethods are implemented. These are called directly, 259All standard Lua metamethods are implemented. These are called directly,
260without shortcuts and on any mix of types. For binary operations, the 260without shortcuts, and on any mix of types. For binary operations, the
261left operand is checked first for a valid ctype metamethod. The 261left operand is checked first for a valid ctype metamethod. The
262<tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt> 262<tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt>
263types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a> 263types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a>
@@ -484,7 +484,7 @@ have some extra methods:
484<p> 484<p>
485Free the resources associated with a callback. The associated Lua 485Free the resources associated with a callback. The associated Lua
486function is unanchored and may be garbage collected. The callback 486function is unanchored and may be garbage collected. The callback
487function pointer is no longer valid and must not be called anymore 487function pointer is no longer valid and must not be called again
488(it may be reused by a subsequently created callback). 488(it may be reused by a subsequently created callback).
489</p> 489</p>
490 490
diff --git a/doc/ext_ffi_semantics.html b/doc/ext_ffi_semantics.html
index 4909fedd..6c6f8ad7 100644
--- a/doc/ext_ffi_semantics.html
+++ b/doc/ext_ffi_semantics.html
@@ -84,7 +84,7 @@ footprint. It's used by the <a href="ext_ffi_api.html">ffi.* library
84functions</a> to declare C&nbsp;types or external symbols. 84functions</a> to declare C&nbsp;types or external symbols.
85</p> 85</p>
86<p> 86<p>
87It's only purpose is to parse C&nbsp;declarations, as found e.g. in 87Its only purpose is to parse C&nbsp;declarations, as found e.g. in
88C&nbsp;header files. Although it does evaluate constant expressions, 88C&nbsp;header files. Although it does evaluate constant expressions,
89it's <em>not</em> a C&nbsp;compiler. The body of <tt>inline</tt> 89it's <em>not</em> a C&nbsp;compiler. The body of <tt>inline</tt>
90C&nbsp;function definitions is simply ignored. 90C&nbsp;function definitions is simply ignored.
@@ -161,7 +161,7 @@ function declarations.</li>
161 161
162</ul> 162</ul>
163<p> 163<p>
164The following C&nbsp;types are pre-defined by the C&nbsp;parser (like 164The following C&nbsp;types are predefined by the C&nbsp;parser (like
165a <tt>typedef</tt>, except re-declarations will be ignored): 165a <tt>typedef</tt>, except re-declarations will be ignored):
166</p> 166</p>
167<ul> 167<ul>
@@ -577,9 +577,9 @@ ffi.new("struct nested", {x=1,y={2,3}}) --> x = 1, y.a = 2, y.b = 3
577 577
578<h2 id="cdata_ops">Operations on cdata Objects</h2> 578<h2 id="cdata_ops">Operations on cdata Objects</h2>
579<p> 579<p>
580All of the standard Lua operators can be applied to cdata objects or a 580All standard Lua operators can be applied to cdata objects or a
581mix of a cdata object and another Lua object. The following list shows 581mix of a cdata object and another Lua object. The following list shows
582the pre-defined operations. 582the predefined operations.
583</p> 583</p>
584<p> 584<p>
585Reference types are dereferenced <em>before</em> performing each of 585Reference types are dereferenced <em>before</em> performing each of
@@ -587,7 +587,7 @@ the operations below &mdash; the operation is applied to the
587C&nbsp;type pointed to by the reference. 587C&nbsp;type pointed to by the reference.
588</p> 588</p>
589<p> 589<p>
590The pre-defined operations are always tried first before deferring to a 590The predefined operations are always tried first before deferring to a
591metamethod or index table (if any) for the corresponding ctype (except 591metamethod or index table (if any) for the corresponding ctype (except
592for <tt>__new</tt>). An error is raised if the metamethod lookup or 592for <tt>__new</tt>). An error is raised if the metamethod lookup or
593index table lookup fails. 593index table lookup fails.
@@ -637,7 +637,7 @@ assigning to an index of a vector raises an error.</li>
637</ul> 637</ul>
638<p> 638<p>
639A ctype object can be indexed with a string key, too. The only 639A ctype object can be indexed with a string key, too. The only
640pre-defined operation is reading scoped constants of 640predefined operation is reading scoped constants of
641<tt>struct</tt>/<tt>union</tt> types. All other accesses defer 641<tt>struct</tt>/<tt>union</tt> types. All other accesses defer
642to the corresponding metamethods or index tables (if any). 642to the corresponding metamethods or index tables (if any).
643</p> 643</p>
@@ -650,7 +650,7 @@ certain optimizations.
650<p> 650<p>
651As a consequence, the <em>elements</em> of complex numbers and 651As a consequence, the <em>elements</em> of complex numbers and
652vectors are immutable. But the elements of an aggregate holding these 652vectors are immutable. But the elements of an aggregate holding these
653types <em>may</em> be modified of course. I.e. you cannot assign to 653types <em>may</em> be modified, of course. I.e. you cannot assign to
654<tt>foo.c.im</tt>, but you can assign a (newly created) complex number 654<tt>foo.c.im</tt>, but you can assign a (newly created) complex number
655to <tt>foo.c</tt>. 655to <tt>foo.c</tt>.
656</p> 656</p>
@@ -669,8 +669,8 @@ through unions is explicitly detected and allowed.
669to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is 669to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is
670defined. The <tt>__new</tt> metamethod is called with the ctype object 670defined. The <tt>__new</tt> metamethod is called with the ctype object
671plus any other arguments passed to the constructor. Note that you have to 671plus any other arguments passed to the constructor. Note that you have to
672use <tt>ffi.new</tt> inside of it, since calling <tt>ct(...)</tt> would 672use <tt>ffi.new</tt> inside the metamethod, since calling <tt>ct(...)</tt>
673cause infinite recursion.</li> 673would cause infinite recursion.</li>
674 674
675<li><b>C&nbsp;function call</b>: a cdata function or cdata function 675<li><b>C&nbsp;function call</b>: a cdata function or cdata function
676pointer can be called. The passed arguments are 676pointer can be called. The passed arguments are
@@ -681,7 +681,7 @@ variable argument part of vararg C&nbsp;function use
681C&nbsp;function is called and the return value (if any) is 681C&nbsp;function is called and the return value (if any) is
682<a href="#convert_tolua">converted to a Lua object</a>.<br> 682<a href="#convert_tolua">converted to a Lua object</a>.<br>
683On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically 683On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically
684detected and a function declared as <tt>__cdecl</tt> (the default) is 684detected, and a function declared as <tt>__cdecl</tt> (the default) is
685silently fixed up after the first call.</li> 685silently fixed up after the first call.</li>
686 686
687</ul> 687</ul>
@@ -691,7 +691,7 @@ silently fixed up after the first call.</li>
691 691
692<li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata 692<li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata
693number or a Lua number can be added or subtracted. The number must be 693number or a Lua number can be added or subtracted. The number must be
694on the right hand side for a subtraction. The result is a pointer of 694on the right-hand side for a subtraction. The result is a pointer of
695the same type with an address plus or minus the number value 695the same type with an address plus or minus the number value
696multiplied by the element size in bytes. An error is raised if the 696multiplied by the element size in bytes. An error is raised if the
697element size is undefined.</li> 697element size is undefined.</li>
@@ -706,7 +706,7 @@ operators (<tt>+&nbsp;-&nbsp;*&nbsp;/&nbsp;%&nbsp;^</tt> and unary
706minus) can be applied to two cdata numbers, or a cdata number and a 706minus) can be applied to two cdata numbers, or a cdata number and a
707Lua number. If one of them is an <tt>uint64_t</tt>, the other side is 707Lua number. If one of them is an <tt>uint64_t</tt>, the other side is
708converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation 708converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation
709is performed. Otherwise both sides are converted to an 709is performed. Otherwise, both sides are converted to an
710<tt>int64_t</tt> and a signed arithmetic operation is performed. The 710<tt>int64_t</tt> and a signed arithmetic operation is performed. The
711result is a boxed 64&nbsp;bit cdata object.<br> 711result is a boxed 64&nbsp;bit cdata object.<br>
712 712
@@ -737,7 +737,7 @@ which is compatible with any other pointer type.</li>
737<li><b>64&nbsp;bit integer comparison</b>: two cdata numbers, or a 737<li><b>64&nbsp;bit integer comparison</b>: two cdata numbers, or a
738cdata number and a Lua number can be compared with each other. If one 738cdata number and a Lua number can be compared with each other. If one
739of them is an <tt>uint64_t</tt>, the other side is converted to an 739of them is an <tt>uint64_t</tt>, the other side is converted to an
740<tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise 740<tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise,
741both sides are converted to an <tt>int64_t</tt> and a signed 741both sides are converted to an <tt>int64_t</tt> and a signed
742comparison is performed.<br> 742comparison is performed.<br>
743 743
@@ -762,9 +762,9 @@ keys!</b>
762A cdata object is treated like any other garbage-collected object and 762A cdata object is treated like any other garbage-collected object and
763is hashed and compared by its address for table indexing. Since 763is hashed and compared by its address for table indexing. Since
764there's no interning for cdata value types, the same value may be 764there's no interning for cdata value types, the same value may be
765boxed in different cdata objects with different addresses. Thus 765boxed in different cdata objects with different addresses. Thus,
766<tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to 766<tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to
767the same hash slot and they certainly <b>do not</b> point to the same 767the same hash slot, and they certainly <b>do not</b> point to the same
768hash slot as <tt>t[2]</tt>. 768hash slot as <tt>t[2]</tt>.
769</p> 769</p>
770<p> 770<p>
@@ -786,7 +786,7 @@ the resulting Lua number as a key when indexing tables.<br>
786One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to 786One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to
787the same slot as <tt>t[2]</tt>.</li> 787the same slot as <tt>t[2]</tt>.</li>
788 788
789<li>Otherwise use either <tt>tostring()</tt> on 64&nbsp;bit integers 789<li>Otherwise, use either <tt>tostring()</tt> on 64&nbsp;bit integers
790or complex numbers or combine multiple fields of a cdata aggregate to 790or complex numbers or combine multiple fields of a cdata aggregate to
791a Lua string (e.g. with 791a Lua string (e.g. with
792<a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then 792<a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then
@@ -794,7 +794,7 @@ use the resulting Lua string as a key when indexing tables.</li>
794 794
795<li>Create your own specialized hash table implementation using the 795<li>Create your own specialized hash table implementation using the
796C&nbsp;types provided by the FFI library, just like you would in 796C&nbsp;types provided by the FFI library, just like you would in
797C&nbsp;code. Ultimately this may give much better performance than the 797C&nbsp;code. Ultimately, this may give much better performance than the
798other alternatives or what a generic by-value hash table could 798other alternatives or what a generic by-value hash table could
799possibly provide.</li> 799possibly provide.</li>
800 800
@@ -860,7 +860,7 @@ garbage collector will automatically free the memory used by it (at
860the end of the next GC cycle). 860the end of the next GC cycle).
861</p> 861</p>
862<p> 862<p>
863Please note that pointers themselves are cdata objects, however they 863Please note, that pointers themselves are cdata objects, however they
864are <b>not</b> followed by the garbage collector. So e.g. if you 864are <b>not</b> followed by the garbage collector. So e.g. if you
865assign a cdata array to a pointer, you must keep the cdata object 865assign a cdata array to a pointer, you must keep the cdata object
866holding the array alive as long as the pointer is still in use: 866holding the array alive as long as the pointer is still in use:
@@ -909,18 +909,18 @@ of the function pointer and the Lua function object (closure).
909</p> 909</p>
910<p> 910<p>
911This can happen implicitly due to the usual conversions, e.g. when 911This can happen implicitly due to the usual conversions, e.g. when
912passing a Lua function to a function pointer argument. Or you can use 912passing a Lua function to a function pointer argument. Or, you can use
913<tt>ffi.cast()</tt> to explicitly cast a Lua function to a 913<tt>ffi.cast()</tt> to explicitly cast a Lua function to a
914C&nbsp;function pointer. 914C&nbsp;function pointer.
915</p> 915</p>
916<p> 916<p>
917Currently only certain C&nbsp;function types can be used as callback 917Currently, only certain C&nbsp;function types can be used as callback
918functions. Neither C&nbsp;vararg functions nor functions with 918functions. Neither C&nbsp;vararg functions nor functions with
919pass-by-value aggregate argument or result types are supported. There 919pass-by-value aggregate argument or result types are supported. There
920are no restrictions for the kind of Lua functions that can be called 920are no restrictions on the kind of Lua functions that can be called
921from the callback &mdash; no checks for the proper number of arguments 921from the callback &mdash; no checks for the proper number of arguments
922are made. The return value of the Lua function will be converted to the 922are made. The return value of the Lua function will be converted to the
923result type and an error will be thrown for invalid conversions. 923result type, and an error will be thrown for invalid conversions.
924</p> 924</p>
925<p> 925<p>
926It's allowed to throw errors across a callback invocation, but it's not 926It's allowed to throw errors across a callback invocation, but it's not
@@ -981,7 +981,7 @@ convention cannot be automatically detected, unlike for
981<tt>__stdcall</tt> calls <em>to</em> Windows functions. 981<tt>__stdcall</tt> calls <em>to</em> Windows functions.
982</p> 982</p>
983<p> 983<p>
984For some use cases it's necessary to free up the resources or to 984For some use cases, it's necessary to free up the resources or to
985dynamically redirect callbacks. Use an explicit cast to a 985dynamically redirect callbacks. Use an explicit cast to a
986C&nbsp;function pointer and keep the resulting cdata object. Then use 986C&nbsp;function pointer and keep the resulting cdata object. Then use
987the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a> 987the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a>
@@ -1034,7 +1034,7 @@ GUI application, which waits for user input most of the time, anyway.
1034</p> 1034</p>
1035<p> 1035<p>
1036For new designs <b>avoid push-style APIs</b>: a C&nbsp;function repeatedly 1036For new designs <b>avoid push-style APIs</b>: a C&nbsp;function repeatedly
1037calling a callback for each result. Instead <b>use pull-style APIs</b>: 1037calling a callback for each result. Instead, <b>use pull-style APIs</b>:
1038call a C&nbsp;function repeatedly to get a new result. Calls from Lua 1038call a C&nbsp;function repeatedly to get a new result. Calls from Lua
1039to C via the FFI are much faster than the other way round. Most well-designed 1039to C via the FFI are much faster than the other way round. Most well-designed
1040libraries already use pull-style APIs (read/write, get/put). 1040libraries already use pull-style APIs (read/write, get/put).
@@ -1053,7 +1053,7 @@ function.
1053</p> 1053</p>
1054<p> 1054<p>
1055Indexing a C&nbsp;library namespace object with a symbol name (a Lua 1055Indexing a C&nbsp;library namespace object with a symbol name (a Lua
1056string) automatically binds it to the library. First the symbol type 1056string) automatically binds it to the library. First, the symbol type
1057is resolved &mdash; it must have been declared with 1057is resolved &mdash; it must have been declared with
1058<a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the 1058<a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the
1059symbol address is resolved by searching for the symbol name in the 1059symbol address is resolved by searching for the symbol name in the
@@ -1108,7 +1108,7 @@ Performance notice: the JIT compiler specializes to the identity of
1108namespace objects and to the strings used to index it. This 1108namespace objects and to the strings used to index it. This
1109effectively turns function cdata objects into constants. It's not 1109effectively turns function cdata objects into constants. It's not
1110useful and actually counter-productive to explicitly cache these 1110useful and actually counter-productive to explicitly cache these
1111function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH it 1111function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH, it
1112<em>is</em> useful to cache the namespace itself, e.g. <tt>local C = 1112<em>is</em> useful to cache the namespace itself, e.g. <tt>local C =
1113ffi.C</tt>. 1113ffi.C</tt>.
1114</p> 1114</p>
@@ -1133,14 +1133,14 @@ This behavior is inevitable, since the goal is to provide full
1133interoperability with C&nbsp;code. Adding extra safety measures, like 1133interoperability with C&nbsp;code. Adding extra safety measures, like
1134bounds checks, would be futile. There's no way to detect 1134bounds checks, would be futile. There's no way to detect
1135misdeclarations of C&nbsp;functions, since shared libraries only 1135misdeclarations of C&nbsp;functions, since shared libraries only
1136provide symbol names, but no type information. Likewise there's no way 1136provide symbol names, but no type information. Likewise, there's no way
1137to infer the valid range of indexes for a returned pointer. 1137to infer the valid range of indexes for a returned pointer.
1138</p> 1138</p>
1139<p> 1139<p>
1140Again: the FFI library is a low-level library. This implies it needs 1140Again: the FFI library is a low-level library. This implies it needs
1141to be used with care, but it's flexibility and performance often 1141to be used with care, but it's flexibility and performance often
1142outweigh this concern. If you're a C or C++ developer, it'll be easy 1142outweigh this concern. If you're a C or C++ developer, it'll be easy
1143to apply your existing knowledge. OTOH writing code for the FFI 1143to apply your existing knowledge. OTOH, writing code for the FFI
1144library is not for the faint of heart and probably shouldn't be the 1144library is not for the faint of heart and probably shouldn't be the
1145first exercise for someone with little experience in Lua, C or C++. 1145first exercise for someone with little experience in Lua, C or C++.
1146</p> 1146</p>
@@ -1168,7 +1168,7 @@ currently incomplete:
1168<li>C&nbsp;declarations are not passed through a C&nbsp;pre-processor, 1168<li>C&nbsp;declarations are not passed through a C&nbsp;pre-processor,
1169yet.</li> 1169yet.</li>
1170<li>The C&nbsp;parser is able to evaluate most constant expressions 1170<li>The C&nbsp;parser is able to evaluate most constant expressions
1171commonly found in C&nbsp;header files. However it doesn't handle the 1171commonly found in C&nbsp;header files. However, it doesn't handle the
1172full range of C&nbsp;expression semantics and may fail for some 1172full range of C&nbsp;expression semantics and may fail for some
1173obscure constructs.</li> 1173obscure constructs.</li>
1174<li><tt>static const</tt> declarations only work for integer types 1174<li><tt>static const</tt> declarations only work for integer types
diff --git a/doc/ext_ffi_tutorial.html b/doc/ext_ffi_tutorial.html
index c5e423b8..de6b6f5e 100644
--- a/doc/ext_ffi_tutorial.html
+++ b/doc/ext_ffi_tutorial.html
@@ -81,7 +81,7 @@ of its functions:
81local ffi = require("ffi") 81local ffi = require("ffi")
82</pre> 82</pre>
83<p> 83<p>
84Please note this doesn't define an <tt>ffi</tt> variable in the table 84Please note, this doesn't define an <tt>ffi</tt> variable in the table
85of globals &mdash; you really need to use the local variable. The 85of globals &mdash; you really need to use the local variable. The
86<tt>require</tt> function ensures the library is only loaded once. 86<tt>require</tt> function ensures the library is only loaded once.
87</p> 87</p>
@@ -190,7 +190,7 @@ don't need to declare them as such.
190<span class="mark">&#9316;</span> The <tt>poll()</tt> 190<span class="mark">&#9316;</span> The <tt>poll()</tt>
191function takes a couple more arguments we're not going to use. You can 191function takes a couple more arguments we're not going to use. You can
192simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt> 192simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt>
193for the <tt>nfds</tt> parameter. Please note that the 193for the <tt>nfds</tt> parameter. Please note, that the
194number&nbsp;<tt>0</tt> <em>does not convert to a pointer value</em>, 194number&nbsp;<tt>0</tt> <em>does not convert to a pointer value</em>,
195unlike in C++. You really have to pass pointers to pointer arguments 195unlike in C++. You really have to pass pointers to pointer arguments
196and numbers to number arguments. 196and numbers to number arguments.
@@ -287,12 +287,12 @@ Here's the step-by-step explanation:
287<p> 287<p>
288<span class="mark">&#9312;</span> This defines some of the 288<span class="mark">&#9312;</span> This defines some of the
289C&nbsp;functions provided by zlib. For the sake of this example, some 289C&nbsp;functions provided by zlib. For the sake of this example, some
290type indirections have been reduced and it uses the pre-defined 290type indirections have been reduced and it uses the predefined
291fixed-size integer types, while still adhering to the zlib API/ABI. 291fixed-size integer types, while still adhering to the zlib API/ABI.
292</p> 292</p>
293<p> 293<p>
294<span class="mark">&#9313;</span> This loads the zlib shared 294<span class="mark">&#9313;</span> This loads the zlib shared
295library. On POSIX systems it's named <tt>libz.so</tt> and usually 295library. On POSIX systems, it's named <tt>libz.so</tt> and usually
296comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any 296comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any
297missing standard prefixes/suffixes, we can simply load the 297missing standard prefixes/suffixes, we can simply load the
298<tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and 298<tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and
@@ -320,7 +320,7 @@ actual length that was used.
320<p> 320<p>
321In C you'd pass in the address of a local variable 321In C you'd pass in the address of a local variable
322(<tt>&amp;buflen</tt>). But since there's no address-of operator in 322(<tt>&amp;buflen</tt>). But since there's no address-of operator in
323Lua, we'll just pass in a one-element array. Conveniently it can be 323Lua, we'll just pass in a one-element array. Conveniently, it can be
324initialized with the maximum buffer size in one step. Calling the 324initialized with the maximum buffer size in one step. Calling the
325actual <tt>zlib.compress2</tt> function is then straightforward. 325actual <tt>zlib.compress2</tt> function is then straightforward.
326</p> 326</p>
@@ -344,7 +344,7 @@ for garbage collection and string interning.
344<span class="mark">&#9317;</span> The <tt>uncompress</tt> 344<span class="mark">&#9317;</span> The <tt>uncompress</tt>
345functions does the exact opposite of the <tt>compress</tt> function. 345functions does the exact opposite of the <tt>compress</tt> function.
346The compressed data doesn't include the size of the original string, 346The compressed data doesn't include the size of the original string,
347so this needs to be passed in. Otherwise no surprises here. 347so this needs to be passed in. Otherwise, no surprises here.
348</p> 348</p>
349<p> 349<p>
350<span class="mark">&#9318;</span> The code, that makes use 350<span class="mark">&#9318;</span> The code, that makes use
@@ -378,7 +378,7 @@ Ok, so the <tt>ffi.*</tt> functions generally accept cdata objects
378wherever you'd want to use a number. That's why we get a away with 378wherever you'd want to use a number. That's why we get a away with
379passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua 379passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua
380library functions or modules don't know how to deal with this. So for 380library functions or modules don't know how to deal with this. So for
381maximum portability one needs to use <tt>tonumber()</tt> on returned 381maximum portability, one needs to use <tt>tonumber()</tt> on returned
382<tt>long</tt> results before passing them on. Otherwise the 382<tt>long</tt> results before passing them on. Otherwise the
383application might work on some systems, but would fail in a POSIX/x64 383application might work on some systems, but would fail in a POSIX/x64
384environment. 384environment.
@@ -450,7 +450,7 @@ the origin.
450</p> 450</p>
451<p> 451<p>
452<span class="mark">&#9315;</span> If we run out of operators, we can 452<span class="mark">&#9315;</span> If we run out of operators, we can
453define named methods, too. Here the <tt>__index</tt> table defines an 453define named methods, too. Here, the <tt>__index</tt> table defines an
454<tt>area</tt> function. For custom indexing needs, one might want to 454<tt>area</tt> function. For custom indexing needs, one might want to
455define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead. 455define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead.
456</p> 456</p>
@@ -464,13 +464,13 @@ be used e.g. to create an array of points. The metamethods automatically
464apply to any and all uses of this type. 464apply to any and all uses of this type.
465</p> 465</p>
466<p> 466<p>
467Please note that the association with a metatable is permanent and 467Please note, that the association with a metatable is permanent and
468<b>the metatable must not be modified afterwards!</b> Ditto for the 468<b>the metatable must not be modified afterwards!</b> Ditto for the
469<tt>__index</tt> table. 469<tt>__index</tt> table.
470</p> 470</p>
471<p> 471<p>
472<span class="mark">&#9317;</span> Here are some simple usage examples 472<span class="mark">&#9317;</span> Here are some simple usage examples
473for the point type and their expected results. The pre-defined 473for the point type and their expected results. The predefined
474operations (such as <tt>a.x</tt>) can be freely mixed with the newly 474operations (such as <tt>a.x</tt>) can be freely mixed with the newly
475defined metamethods. Note that <tt>area</tt> is a method and must be 475defined metamethods. Note that <tt>area</tt> is a method and must be
476called with the Lua syntax for methods: <tt>a:area()</tt>, not 476called with the Lua syntax for methods: <tt>a:area()</tt>, not
@@ -479,7 +479,7 @@ called with the Lua syntax for methods: <tt>a:area()</tt>, not
479<p> 479<p>
480The C&nbsp;type metamethod mechanism is most useful when used in 480The C&nbsp;type metamethod mechanism is most useful when used in
481conjunction with C&nbsp;libraries that are written in an object-oriented 481conjunction with C&nbsp;libraries that are written in an object-oriented
482style. Creators return a pointer to a new instance and methods take an 482style. Creators return a pointer to a new instance, and methods take an
483instance pointer as the first argument. Sometimes you can just point 483instance pointer as the first argument. Sometimes you can just point
484<tt>__index</tt> to the library namespace and <tt>__gc</tt> to the 484<tt>__index</tt> to the library namespace and <tt>__gc</tt> to the
485destructor and you're done. But often enough you'll want to add 485destructor and you're done. But often enough you'll want to add
@@ -565,7 +565,7 @@ end
565</pre> 565</pre>
566<p> 566<p>
567This turns them into indirect calls and generates bigger and slower 567This turns them into indirect calls and generates bigger and slower
568machine code. Instead you'll want to cache the namespace itself and 568machine code. Instead, you'll want to cache the namespace itself and
569rely on the JIT compiler to eliminate the lookups: 569rely on the JIT compiler to eliminate the lookups:
570</p> 570</p>
571<pre class="code"> 571<pre class="code">
diff --git a/doc/ext_jit.html b/doc/ext_jit.html
index be1bdcf6..8f58a0c7 100644
--- a/doc/ext_jit.html
+++ b/doc/ext_jit.html
@@ -150,7 +150,7 @@ Contains the target architecture name:
150 150
151<h2 id="jit_opt"><tt>jit.opt.*</tt> &mdash; JIT compiler optimization control</h2> 151<h2 id="jit_opt"><tt>jit.opt.*</tt> &mdash; JIT compiler optimization control</h2>
152<p> 152<p>
153This sub-module provides the backend for the <tt>-O</tt> command line 153This submodule provides the backend for the <tt>-O</tt> command line
154option. 154option.
155</p> 155</p>
156<p> 156<p>
@@ -170,7 +170,7 @@ which was one of the ways to enable optimization.
170 170
171<h2 id="jit_util"><tt>jit.util.*</tt> &mdash; JIT compiler introspection</h2> 171<h2 id="jit_util"><tt>jit.util.*</tt> &mdash; JIT compiler introspection</h2>
172<p> 172<p>
173This sub-module holds functions to introspect the bytecode, generated 173This submodule holds functions to introspect the bytecode, generated
174traces, the IR and the generated machine code. The functionality 174traces, the IR and the generated machine code. The functionality
175provided by this module is still in flux and therefore undocumented. 175provided by this module is still in flux and therefore undocumented.
176</p> 176</p>
diff --git a/doc/extensions.html b/doc/extensions.html
index fe4df6f7..3ed13804 100644
--- a/doc/extensions.html
+++ b/doc/extensions.html
@@ -84,7 +84,7 @@ or LuaJIT.
84</p> 84</p>
85<p> 85<p>
86LuaJIT extends the standard Lua VM with new functionality and adds 86LuaJIT extends the standard Lua VM with new functionality and adds
87several extension modules. Please note this page is only about 87several extension modules. Please note, this page is only about
88<em>functional</em> enhancements and not about performance enhancements, 88<em>functional</em> enhancements and not about performance enhancements,
89such as the optimized VM, the faster interpreter or the JIT compiler. 89such as the optimized VM, the faster interpreter or the JIT compiler.
90</p> 90</p>
@@ -185,7 +185,7 @@ usage. See also the
185</p> 185</p>
186<p> 186<p>
187The generated bytecode is portable and can be loaded on any architecture 187The generated bytecode is portable and can be loaded on any architecture
188that LuaJIT supports, independent of word size or endianess. However the 188that LuaJIT supports, independent of word size or endianess. However, the
189bytecode compatibility versions must match. Bytecode stays compatible 189bytecode compatibility versions must match. Bytecode stays compatible
190for dot releases (x.y.0 &rarr; x.y.1), but may change with major or 190for dot releases (x.y.0 &rarr; x.y.1), but may change with major or
191minor releases (2.0 &rarr; 2.1) or between any beta release. Foreign 191minor releases (2.0 &rarr; 2.1) or between any beta release. Foreign
@@ -197,7 +197,7 @@ bytecode (e.g. from Lua 5.1) is incompatible and cannot be loaded.
197LuaJIT uses a Tausworthe PRNG with period 2^223 to implement 197LuaJIT uses a Tausworthe PRNG with period 2^223 to implement
198<tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of 198<tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of
199the PRNG results is much superior compared to the standard Lua 199the PRNG results is much superior compared to the standard Lua
200implementation which uses the platform-specific ANSI rand(). 200implementation, which uses the platform-specific ANSI rand().
201</p> 201</p>
202<p> 202<p>
203The PRNG generates the same sequences from the same seeds on all 203The PRNG generates the same sequences from the same seeds on all
@@ -215,7 +215,7 @@ Important: Neither this nor any other PRNG based on the simplistic
215<h3 id="io"><tt>io.*</tt> functions handle 64&nbsp;bit file offsets</h3> 215<h3 id="io"><tt>io.*</tt> functions handle 64&nbsp;bit file offsets</h3>
216<p> 216<p>
217The file I/O functions in the standard <tt>io.*</tt> library handle 217The file I/O functions in the standard <tt>io.*</tt> library handle
21864&nbsp;bit file offsets. In particular this means it's possible 21864&nbsp;bit file offsets. In particular, this means it's possible
219to open files larger than 2&nbsp;Gigabytes and to reposition or obtain 219to open files larger than 2&nbsp;Gigabytes and to reposition or obtain
220the current file position for offsets beyond 2&nbsp;GB 220the current file position for offsets beyond 2&nbsp;GB
221(<tt>fp:seek()</tt> method). 221(<tt>fp:seek()</tt> method).
diff --git a/doc/faq.html b/doc/faq.html
index 36b2eafc..0b4b2df0 100644
--- a/doc/faq.html
+++ b/doc/faq.html
@@ -116,7 +116,7 @@ Direct3D version 10 or higher do not show this behavior anymore.
116Consider testing your application with older versions, too.<br> 116Consider testing your application with older versions, too.<br>
117 117
118Similarly, the Borland/Delphi runtime modifies the FPU control word and 118Similarly, the Borland/Delphi runtime modifies the FPU control word and
119enables FP exceptions. Of course this violates the Windows ABI, too. 119enables FP exceptions. Of course, this violates the Windows ABI, too.
120Please check the Delphi docs for the Set8087CW method.</dd> 120Please check the Delphi docs for the Set8087CW method.</dd>
121</dl> 121</dl>
122 122
@@ -126,7 +126,7 @@ Please check the Delphi docs for the Set8087CW method.</dd>
126ignored by compiled code. If your program is running in a tight loop 126ignored by compiled code. If your program is running in a tight loop
127and never falls back to the interpreter, the debug hook never runs and 127and never falls back to the interpreter, the debug hook never runs and
128can't throw the "interrupted!" error.<br> 128can't throw the "interrupted!" error.<br>
129You have to press Ctrl-C twice to get stop your program. That's similar 129You have to press Ctrl-C twice to stop your program. That's similar
130to when it's stuck running inside a C function under the Lua interpreter.</dd> 130to when it's stuck running inside a C function under the Lua interpreter.</dd>
131</dl> 131</dl>
132 132
@@ -146,7 +146,7 @@ so it doesn't rely on the key order. Or sort the table keys, if you must.</dd>
146<dl id="sandbox"> 146<dl id="sandbox">
147<dt>Q: Can Lua code be safely sandboxed?</dt> 147<dt>Q: Can Lua code be safely sandboxed?</dt>
148<dd> 148<dd>
149Maybe for an extremly restricted subset of Lua and if you relentlessly 149Maybe for an extremely restricted subset of Lua and if you relentlessly
150scrutinize every single interface function you offer to the untrusted code.<br> 150scrutinize every single interface function you offer to the untrusted code.<br>
151 151
152Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks), 152Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks),
diff --git a/doc/install.html b/doc/install.html
index 19fab1b8..fe89fc5c 100644
--- a/doc/install.html
+++ b/doc/install.html
@@ -317,7 +317,7 @@ The recommended way to fetch the latest version is to do a pull from
317the git repository. 317the git repository.
318</p> 318</p>
319<p> 319<p>
320Alternatively download the latest source package of LuaJIT (pick the .tar.gz). 320Alternatively, download the latest source package of LuaJIT (pick the .tar.gz).
321Move it to a directory of your choice, open a terminal window and change 321Move it to a directory of your choice, open a terminal window and change
322to this directory. Now unpack the archive and change to the newly created 322to this directory. Now unpack the archive and change to the newly created
323directory (replace XX.YY.ZZ with the version you downloaded): 323directory (replace XX.YY.ZZ with the version you downloaded):
@@ -475,7 +475,7 @@ important to compile with the proper CPU or architecture settings. You
475can specify these when building the toolchain yourself. Or add 475can specify these when building the toolchain yourself. Or add
476<tt>-mcpu=...</tt> or <tt>-march=...</tt> to <tt>TARGET_CFLAGS</tt>. For 476<tt>-mcpu=...</tt> or <tt>-march=...</tt> to <tt>TARGET_CFLAGS</tt>. For
477ARM it's important to have the correct <tt>-mfloat-abi=...</tt> setting, 477ARM it's important to have the correct <tt>-mfloat-abi=...</tt> setting,
478too. Otherwise LuaJIT may not run at the full performance of your target 478too. Otherwise, LuaJIT may not run at the full performance of your target
479CPU. 479CPU.
480</p> 480</p>
481<pre class="code"> 481<pre class="code">
@@ -619,7 +619,7 @@ allocator from your system (no support for this on 64&nbsp;bit architectures).</
619of calling <tt>luaopen_base</tt> etc. directly.</li> 619of calling <tt>luaopen_base</tt> etc. directly.</li>
620<li>To change or extend the list of standard libraries to load, copy 620<li>To change or extend the list of standard libraries to load, copy
621<tt>src/lib_init.c</tt> to your project and modify it accordingly. 621<tt>src/lib_init.c</tt> to your project and modify it accordingly.
622Make sure the <tt>jit</tt> library is loaded or the JIT compiler 622Make sure the <tt>jit</tt> library is loaded, or the JIT compiler
623will not be activated.</li> 623will not be activated.</li>
624<li>The <tt>bit.*</tt> module for bitwise operations 624<li>The <tt>bit.*</tt> module for bitwise operations
625is already built-in. There's no need to statically link 625is already built-in. There's no need to statically link
@@ -638,7 +638,7 @@ in unspeakable ways.
638There should be absolutely no need to patch <tt>luaconf.h</tt> or any 638There should be absolutely no need to patch <tt>luaconf.h</tt> or any
639of the Makefiles. And please do not hand-pick files for your packages &mdash; 639of the Makefiles. And please do not hand-pick files for your packages &mdash;
640simply use whatever <tt>make install</tt> creates. There's a reason 640simply use whatever <tt>make install</tt> creates. There's a reason
641for all of the files <em>and</em> directories it creates. 641for all the files <em>and</em> directories it creates.
642</p> 642</p>
643<p> 643<p>
644The build system uses GNU make and auto-detects most settings based on 644The build system uses GNU make and auto-detects most settings based on
diff --git a/doc/running.html b/doc/running.html
index 2ce02bc4..3f408141 100644
--- a/doc/running.html
+++ b/doc/running.html
@@ -179,7 +179,7 @@ written in Lua. They are mainly used for debugging the JIT compiler
179itself. For a description of their options and output format, please 179itself. For a description of their options and output format, please
180read the comment block at the start of their source. 180read the comment block at the start of their source.
181They can be found in the <tt>lib</tt> directory of the source 181They can be found in the <tt>lib</tt> directory of the source
182distribution or installed under the <tt>jit</tt> directory. By default 182distribution or installed under the <tt>jit</tt> directory. By default,
183this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX 183this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX
184systems (replace XX.YY.ZZ by the installed version). 184systems (replace XX.YY.ZZ by the installed version).
185</p> 185</p>
@@ -211,7 +211,7 @@ to a specific value.
211You can either use this option multiple times (like <tt>-Ocse 211You can either use this option multiple times (like <tt>-Ocse
212-O-dce -Ohotloop=10</tt>) or separate several settings with a comma 212-O-dce -Ohotloop=10</tt>) or separate several settings with a comma
213(like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from 213(like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from
214left to right and later settings override earlier ones. You can freely 214left to right, and later settings override earlier ones. You can freely
215mix the three forms, but note that setting an optimization level 215mix the three forms, but note that setting an optimization level
216overrides all earlier flags. 216overrides all earlier flags.
217</p> 217</p>
diff --git a/doc/status.html b/doc/status.html
index c251d224..7ecedf3d 100644
--- a/doc/status.html
+++ b/doc/status.html
@@ -79,7 +79,7 @@ Known incompatibilities and issues in LuaJIT&nbsp;2.0:
79<ul> 79<ul>
80<li> 80<li>
81There are some differences in <b>implementation-defined</b> behavior. 81There are some differences in <b>implementation-defined</b> behavior.
82These either have a good reason, are arbitrary design choices 82These either have a good reason, are arbitrary design choices,
83or are due to quirks in the VM. The latter cases may get fixed if a 83or are due to quirks in the VM. The latter cases may get fixed if a
84demonstrable need is shown. 84demonstrable need is shown.
85</li> 85</li>
@@ -89,7 +89,7 @@ hooks for non-Lua functions) and shows slightly different behavior
89in LuaJIT (no per-coroutine hooks, no tail call counting). 89in LuaJIT (no per-coroutine hooks, no tail call counting).
90</li> 90</li>
91<li> 91<li>
92Currently some <b>out-of-memory</b> errors from <b>on-trace code</b> are not 92Currently, some <b>out-of-memory</b> errors from <b>on-trace code</b> are not
93handled correctly. The error may fall through an on-trace 93handled correctly. The error may fall through an on-trace
94<tt>pcall</tt> or it may be passed on to the function set with 94<tt>pcall</tt> or it may be passed on to the function set with
95<tt>lua_atpanic</tt> on x64. 95<tt>lua_atpanic</tt> on x64.