| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
* maint:
zip: Eliminate leak of open file after crash
zip: Don't crash when a zip file has an Unix extra header
|
|
zip: Fix bugs ERL-348 and ERL-349
OTP-14246
|
|
stdlib: Fix mime_decode/1 binary matching performance
OTP-14245
|
|
* maint:
stdlib: Add maps to term traversal
|
|
* hasse/stdlib/fix_term_traversal:
stdlib: Add maps to term traversal
|
|
Better error descriptions for ASN.1 encoding/decoding failures
|
|
Make sure that zip:extract() and zip:create() closes the zip
file if there is an error.
ERL-349
|
|
There is unfinished code in the zip module to handle the
extra field in the central-directory header for each
file. The code to extract an Unix extra subfield is incorrect
and always causes a bad_unix_extra_field error. A further
flaw in the code is that it expects that there is only
a single subfield.
Correcting the code for extracting extra subfields will not do any
good, because the extracted data is ignored. In fact, not even the
file times extracted from DOS file times are used for some reason.
Therefore, don't correct the unfinished code. Remove it completely.
(If needed, extending zip to use file times and to use the information
in the extra field should be done in a major release, not in a
maintenance release.)
ERL-348
|
|
Symptom: Throughput of base64:mime_decode/1 significantly lower than
base64:decode/1.
Problem: tail_contains_more/2 prevents compiler from delaying creation
of sub binaries.
Solution: Restructure mime_decode_binary/2 to use binary matching best
practices from the Efficiency Guide.
See ERL-366
|
|
* maint:
Documentation: use behaviour(ssh_daemon_channel)
Fix minor typo in compile:forms/1 doc
|
|
Fix minor typo in compile:forms/1 doc
OTP-14240
|
|
|
|
* bjorn/compiler/opt-binary-strings/OTP-14125:
v3_core: Combine binary strings to larger integers
|
|
Binary construction that mixes long literal strings with variables
will make Dialyzer slow. Example:
<<"long string (thousand of characters)",T/binary>>
The string literals in binary construction is translated to one binary
segment per character; all those segments will slow down Dialyzer.
We can speed up Dialyzer if we combine several characters (up to 256)
to a signle segment in the binary. It will also slightly speed up the
compiler.
This optimization will make core listings file with binary strings
harder to read, but they were not that easy to read before this
change.
ERL-308
|
|
* egil/pretty-print-maps-smaller/OTP-14239:
stdlib: Use erts_internal:maps_to_list/2 in io_lib_pretty
Update preloaded erts_internal.beam
erts: Test erts_internal:maps_to_list/2
erts: Introduce erts_internal:maps_to_list/2
|
|
|
|
In the SSH User's Guide, section 2.8 'Creating a Subsystem' uses
behaviour(ssh_subsystem) but should use behaviour(ssh_daemon_channel).
The renaming was updated in the Reference Manual but never reflected
in the User's Guide.
|
|
|
|
ErLLVM: Drop support for LLVM<3.9 in R20
|
|
|
|
* maint:
filename: Add safe_relative_path/1
Conflicts:
lib/stdlib/src/filename.erl
|
|
filename: Add safe_relative_path/1
OTP-14215
|
|
* bjorn/stdlib/misc-fixes:
c: Reintroduce support for non-list options in c/2
c: Remove unused import of lists:concat/1
|
|
|
|
* hasse/stdlib/sofs_opt/OTP-14157:
stdlib: Simplify error handling of the sofs module
|
|
|
|
* ingela/ssl/default-ciphers-suites/OTP-14235:
ssl: Always prefer AES over 3DES
|
|
|
|
* lukas/kernel/fix_os_cmd_close_race/OTP-14232:
kernel: Fix hanging os:cmd race condition
|
|
Atoms ('badarg', 'type_mismatch', &c) are used as errors instead of
tuples containing the parameters. This makes it possible for the
garbage collector to reclaim memory earlier.
Since the exact format of error tuples is undocumented no release note
is deemed necessary.
|
|
|
|
* lukas/kernel/fail-sticky_dir-if-not-sticky:
kernel: Fail sticky_dir tc if module not sticky
|
|
* maint:
[xmerl] Remove faulty throws
[xmerl] Fix XML "well-formedness" bug i SAX parser
[xmerl] Correct bug handling multiple documents on a stream
stdlib: Improve pretty-printing of terms with maps
Conflicts:
lib/stdlib/test/io_SUITE.erl
|
|
Document ssl_session_cache_api's size/1 callback
|
|
Before 0eb45e21d40 it was possible to write (for example):
c(m, dcore)
instead of the more verbose:
c(m, [dcore])
Reintroduce this convenient shortcut.
|
|
|
|
|
|
* hasse/stdlib/fix_pretty_maps/OTP-14175:
stdlib: Improve pretty-printing of terms with maps
|
|
* lars/xmerl/sax-parser-multi-doc-problem:
[xmerl] Remove faulty throws
[xmerl] Fix XML "well-formedness" bug i SAX parser
[xmerl] Correct bug handling multiple documents on a stream
OTP-14211
OTP-14213
|
|
* siri/ct/get_dirs_from_testspec/OTP-14132:
[ct] Add ct_testspec:get_tests/1
|
|
|
|
Changed the XML Sax parser behaviour so it returns an error
if there are something more in the file after the the
matching document. If one using the xmerl_sax_parser:stream()
a rest is allowed which then can be sent to a new call of
xmerl_sax_parser:stream() to parse next document.
This is done to be compliant with XML conformance tests.
|
|
Change how to interpret end of document to comply with Tim Brays
comment on the standard. This makes it possible to handle more
than one doc on a stream, the standard makes it impossible to
know when the document is ended without waiting for the next
document (and not always even that).
Tim Brays comment about the trailing "Misc" rule:
The fact that you're allowed some trailing junk after the root
element, I decided (but unfortunately too late) is a real design
error in XML. If I'm writing a network client, I'm probably going
to close the link as soon as a I see the root element end-tag, and
not depend on the other end closing it down properly.
Furthermore, if I want to send a succession of XML documents over
a network link, if I find a processing instruction after a root
element, is it a trailer on the previous document, or part of the
prolog of the next?
|
|
AES256 was preferred over 3DES already, so this only makes sure AES128
is preferred over 3DES also. This changes the default but probably
nobody will notice as a better algorithm will be chosen anyhow.
|
|
The generated encode/2 and decode/2 functions can return
cryptic error messages. Consider this ASN.1 spec:
T DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
S ::= SEQUENCE {
b BOOLEAN,
i INTEGER (1..100),
j INTEGER (0..7),
s OCTET STRING
}
END
In OTP 19, the error terms will look like this:
Eshell V8.2 (abort with ^G)
1> asn1ct:compile('T', [ber]).
ok
2> rr('T').
['S']
3> 'T':encode('S', #'S'{}).
{error,{asn1,{encode_boolean,undefined}}}
4> 'T':encode('S', #'S'{b=false}).
{error,{asn1,{encode_integer,undefined}}}
5> 'T':encode('S', #'S'{b=false,i=7,j=0}).
{error,{asn1,function_clause}}
Some error terms are clearer than other. In the first error
term, it is clear that the error refers to the 'b' field,
since there is only one BOOLEAN in 'S'. The second error
term could refer to either 'i' or 'j'. The last error term...
well... in this case we can infer that it must refer to 's'.
The easiest way to provide more information is to include
the stack trace with line numbers in the error term:
3> 'T':encode('S', #'S'{b=false}).
{error,{asn1,{{encode_integer,undefined},
[{'T',encode_integer,2,[{file,"T.erl"},{line,240}]},
{'T',enc_S,2,[{file,"T.erl"},{line,102}]},
{'T',encode,2,[{file,"T.erl"},{line,36}]},
{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]},
{shell,exprs,7,[{file,"shell.erl"},{line,686}]},
{shell,eval_exprs,7,[{file,"shell.erl"},{line,641}]},
{shell,eval_loop,3,[{file,"shell.erl"},{line,626}]}]}}}
By looking at the generated Erlang code, we can see that encoding
failed for 'i'.
This is an compatible change. All that the documentation says is
that the format of the error tuple is:
{error,{asn1,Description}}
With this change, Description is always a tuple:
{ErrorDescription,StackTrace}
Alternatives considered: Providing more information in the error
term itself and make sure there can be no 'function_clause', 'badarg',
or 'badmatch' exceptions. That would be possible, but it would
require a lot of work and it would increase the size of the generated
code and make it slower. Therefore, this solution was rejected.
|
|
|
|
into maint
* legoscia/erl_interface/doc-no-tuple-funs/PR-1343/OTP-14233:
Documentation: tuple funs are unsupported
|
