Age | Commit message (Collapse) | Author |
|
|
|
This adds three new functions to io_lib - scan_format/2, unscan_format/1,
and build_text/1 - which expose the parsed form of the format control
sequences to make it possible to easily modify or filter the input to
io_lib:format/2. This can e.g. be used in order to replace unbounded-size
control sequences like ~w or ~p with corresponding depth-limited ~W and ~P
before doing the actual formatting.
|
|
Ensure that the monitor reference is present in all receive clauses, so
that the compiler optimisation kicks in and the run time won't depend on
the length of the message queue of the calling process.
Remove the 'EXIT' clause, as its presence breaks the optimisation, and
that case is handled by the 'DOWN' clause anyway.
The test io_SUITE:io_with_huge_message_queue is an adaptation of
gen_server_SUITE:call_with_huge_message_queue.
|
|
Values for which the precision or field width were too small in io_lib_format
could trigger an infinite loop or crash in term/5.
Reported-by: Richard Carlsson
|
|
|
|
|
|
|
|
Also fixed otp_10302 to test both on a node with +pc unicode and
a node with +pc latin1.
|
|
The modifier 'l' can be used for turning off the string recognition of
~p and ~P.
|
|
Make sure io_lib:fwrite() with a format string including "~ts" does
not crash when given binaries that cannot be interpreted as
UTF-8-encoded strings.
We want to avoid crashes caused by excessive use of the 't' modifier.
|
|
Binaries were pretty printed too often.
|
|
The code related to the introduction of unicode_string() and
unicode_char() has been removed. The types char() and string() have
been extended to include Unicode characters.
In fact char() was changed some time ago; this commit is about
cleaning up the documentation and introduce better names for some
functions.
|
|
|
|
Expect modifications, additions and corrections.
There is a kludge in file_io_server and
erl_scan:continuation_location() that's not so pleasing.
|
|
A case clause ordering problem is causing the empty binary to be
printed as <<...>> rather than the correct <<>> when using ~W with a
depth of 1. Add new tests to verify correct behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|