| Age | Commit message (Collapse) | Author |
|---|
|
* jw/fix-float-middle-endian/OTP-11201:
Fix binary construction on floating point middle-endian machines
Fix binary matching on floating point middle-endian machines
Fix erlang:phash2() on floating point middle-endian machines
Fix external term format BIFs on floating point middle-endian machines
|
|
This complements 933e701 (OTP-10209).
Simple error example:
1> <<131,70,63,240,0,0,0,0,0,0>> = term_to_binary(1.0, [{minor_version,1}]).
** exception error: no match of right hand side value <<131,70,0,0,0,0,63,240,0,0>>
2> 1.0 = binary_to_term(<<131,70,63,240,0,0,0,0,0,0>>).
** exception error: no match of right hand side value 5.299808824e-315
But roundtrip always works:
3> 1.0 = binary_to_term(term_to_binary(1.0, [{minor_version,1}])).
1.0
|
|
|
|
|
|
This is needed as corruption of the index_uniq byte
can cause very strange behaviour when the fun is called
by native code.
|
|
|
|
|
|
|
|
This BIF's second parameter is a list of options.
Currently the only allowed option is {minor_version, Version}
where version is either 0 (default) or 1.
|
|
concat_binary/1 was deprecated in R13B04, but already in
the R10B-2 release, the documentation recommends using
list_to_binary/1 instead.
|
|
Noticed-by: Jon Meredith
|
|
The io_list_len() function returns an int, where a negative return
value indicates a type error. One problem is that an int only consists
of 32 bits in a 64-bit emulator. Changing the return type to Sint
will solve that problem, but in the 32-bit emulator, a large iolist
and a iolist with a type error will both return a negative number.
(Noticed by Jon Meredith.)
Another problem is that for iolists whose total size exceed the
word size, the result would be truncated, leading to a subsequent
buffer overflow and emulator crash.
Therefore, introduce the new erts_iolist_size() function which
returns a status indication and writes the result size through
a passed pointer. If the result size does not fit in a word,
return an overflow indication.
|
|
iolist_size/1 would silently return a truncated result for iolists
whose size exceeded the word size. For example:
iolist(lists:duplicate(256, <<0:(1 bsl 24)/unit:8>>)).
would return 0 (instead of 4294967296 or 1 bsl 32).
Rewrite iolist_size/1 to accumulate the size in a bignum if
necessary and result the correct result.
|
|
|
|
In older releases of Erlang/OTP, the '=:=' operator could run out
of stack if used to compare very deep lists. Since that problem
has been fixed, we can remove the workaround used in the deep/1
test case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While binary_to_term/2 was added in R13B04, it wasn't auto-imported. This
conformed to longstanding policy of not changing auto-imports between major
versions. This patch contains changes to auto-import binary_to_term/2 to
coincide with the release of R14.
|
|
|
|
fragments was created. This will mainly benefit NIFs that return
large compound terms.
|
|
* jv/binary_to_term-opts:
document ErtsExternalDist flags and CON_ID mask
add options to binary_to_term
OTP-8367 There is new erlang:binary_to_binary/2 BIF that takes an option
list. The option safe can be used to prevent creation of
resources that are not garbage collected (such as atoms). (Thanks
to Jayson Vantuyl.)
|
|
term_to_binary and binary_to_term are powerful tools that can be used easily in
lieu of a custom binary network protocol. Unfortunately, carefully crafted
data can be used to exhaust the memory in an Erlang node by merely attempting
to decode binaries. This makes it unsafe to receive data from untrusted
sources.
This is possible because binary_to_term/1 will allocate new atoms and new
external function references. These data structures are not garbage collected.
This patch implements the new form of binary_to_term that takes a list of
options, and a simple option called 'safe'. If specified, this option will
cause decoding to fail with a badarg error if an atom or external function
reference would be allocated.
In the general case, it will happily decode any Erlang term other than those
containing new atoms or new external function references. However, fun, pid,
and ref data types can embed atoms. They might fail to decode if one of these
embedded atoms is new to the node. This may be an issue if encoded binaries
are transferred between nodes or persisted between invocations of Erlang.
|
|
|
