@@ -160,13 +160,33 @@ <h3 id="xpcall"><tt>xpcall(f, err [,args...])</tt> passes arguments</h3>
160
160
which is called in a protected context.
161
161
</ p >
162
162
163
- < h3 id ="load "> < tt > loadfile ()</ tt > etc. handle UTF-8 source code</ h3 >
163
+ < h3 id ="load "> < tt > load* ()</ tt > handle UTF-8 source code</ h3 >
164
164
< p >
165
165
Non-ASCII characters are handled transparently by the Lua source code parser.
166
166
This allows the use of UTF-8 characters in identifiers and strings.
167
167
A UTF-8 BOM is skipped at the start of the source code.
168
168
</ p >
169
169
170
+ < h3 id ="load_mode "> < tt > load*()</ tt > add a mode parameter</ h3 >
171
+ < p >
172
+ As an extension from Lua 5.2, the functions < tt > loadstring()</ tt > ,
173
+ < tt > loadfile()</ tt > and (new) < tt > load()</ tt > add an optional
174
+ < tt > mode</ tt > parameter.
175
+ </ p >
176
+ < p >
177
+ The default mode string is < tt > "bt"</ tt > , which allows loading of both
178
+ source code and bytecode. Use < tt > "t"</ tt > to allow only source code
179
+ or < tt > "b"</ tt > to allow only bytecode to be loaded.
180
+ </ p >
181
+ < p >
182
+ By default, the < tt > load*</ tt > functions generate the native bytecode format.
183
+ For cross-compilation purposes, add < tt > W</ tt > to the mode string to
184
+ force the 32 bit format and < tt > X</ tt > to force the 64 bit format.
185
+ Add both to force the opposite format. Note that non-native bytecode
186
+ generated by < tt > load*</ tt > cannot be run, but can still be passed
187
+ to < tt > string.dump</ tt > .
188
+ </ p >
189
+
170
190
< h3 id ="tostring "> < tt > tostring()</ tt > etc. canonicalize NaN and ±Inf</ h3 >
171
191
< p >
172
192
All number-to-string conversions consistently convert non-finite numbers
@@ -186,26 +206,33 @@ <h3 id="tonumber"><tt>tonumber()</tt> etc. use builtin string to number conversi
186
206
numbers (e.g. < tt > 0x1.5p-3</ tt > ).
187
207
</ p >
188
208
189
- < h3 id ="string_dump "> < tt > string.dump(f [,strip ])</ tt > generates portable bytecode</ h3 >
209
+ < h3 id ="string_dump "> < tt > string.dump(f [,mode ])</ tt > generates portable bytecode</ h3 >
190
210
< p >
191
211
An extra argument has been added to < tt > string.dump()</ tt > . If set to
192
- < tt > true</ tt > , 'stripped' bytecode without debug information is
193
- generated. This speeds up later bytecode loading and reduces memory
194
- usage. See also the
212
+ < tt > true</ tt > or to a string which contains the character < tt > s </ tt > ,
213
+ 'stripped' bytecode without debug information is generated. This speeds
214
+ up later bytecode loading and reduces memory usage. See also the
195
215
< a href ="running.html#opt_b "> < tt > -b</ tt > command line option</ a > .
196
216
</ p >
197
217
< p >
198
218
The generated bytecode is portable and can be loaded on any architecture
199
- that LuaJIT supports, independent of word size or endianess. However, the
200
- bytecode compatibility versions must match. Bytecode stays compatible
201
- for dot releases (x.y.0 → x.y.1), but may change with major or
202
- minor releases (2.0 → 2.1) or between any beta release. Foreign
203
- bytecode (e.g. from Lua 5.1) is incompatible and cannot be loaded.
219
+ that LuaJIT supports. However, the bytecode compatibility versions must
220
+ match. Bytecode only stays compatible within a major+minor version
221
+ (x.y.aaa → x.y.bbb), except for development branches. Foreign bytecode
222
+ (e.g. from Lua 5.1) is incompatible and cannot be loaded.
204
223
</ p >
205
224
< p >
206
225
Note: < tt > LJ_GC64</ tt > mode requires a different frame layout, which implies
207
- a different, incompatible bytecode format for all 64 bit ports. This may be
208
- rectified in the future.
226
+ a different, incompatible bytecode format between 32 bit and 64 bit ports.
227
+ This may be rectified in the future. In the meantime, use the < tt > W</ tt >
228
+ and </ tt > X</ tt > < a href ="#load_mode "> modes of the < tt > load*</ tt > functions</ a >
229
+ for cross-compilation purposes.
230
+ </ p >
231
+ < p >
232
+ Due to VM hardening, bytecode is not deterministic. Add < tt > d</ tt > to the
233
+ mode string to dump it in a deterministic manner: identical source code
234
+ always gives a byte-for-byte identical bytecode dump. This feature is
235
+ mainly useful for reproducible builds.
209
236
</ p >
210
237
211
238
< h3 id ="table_new "> < tt > table.new(narray, nhash)</ tt > allocates a pre-sized table</ h3 >
@@ -238,7 +265,7 @@ <h3 id="math_random">Enhanced PRNG for <tt>math.random()</tt></h3>
238
265
LuaJIT uses a Tausworthe PRNG with period 2^223 to implement
239
266
< tt > math.random()</ tt > and < tt > math.randomseed()</ tt > . The quality of
240
267
the PRNG results is much superior compared to the standard Lua
241
- implementation, which uses the platform-specific ANSI rand().
268
+ implementation, which uses the platform-specific ANSI < tt > rand()</ tt > .
242
269
</ p >
243
270
< p >
244
271
The PRNG generates the same sequences from the same seeds on all
@@ -249,6 +276,10 @@ <h3 id="math_random">Enhanced PRNG for <tt>math.random()</tt></h3>
249
276
preserve uniformity.
250
277
</ p >
251
278
< p >
279
+ Call < tt > math.randomseed()</ tt > without any arguments to seed it from
280
+ system entropy.
281
+ </ p >
282
+ < p >
252
283
Important: Neither this nor any other PRNG based on the simplistic
253
284
< tt > math.random()</ tt > API is suitable for cryptographic use.
254
285
</ p >
@@ -286,7 +317,7 @@ <h2 id="lua52">Extensions from Lua 5.2</h2>
286
317
</ p >
287
318
< ul >
288
319
< li > < tt > goto</ tt > and < tt > ::labels::</ tt > .</ li >
289
- < li > Hex escapes < tt > '\x3F'</ tt > and < tt > '\* '</ tt > escape in strings.</ li >
320
+ < li > Hex escapes < tt > '\x3F'</ tt > and < tt > '\z '</ tt > escape in strings.</ li >
290
321
< li > < tt > load(string|reader [, chunkname [,mode [,env]]])</ tt > .</ li >
291
322
< li > < tt > loadstring()</ tt > is an alias for < tt > load()</ tt > .</ li >
292
323
< li > < tt > loadfile(filename [,mode [,env]])</ tt > .</ li >
0 commit comments