| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* jxck/fix-doc-typo/PR-1238:
fix typo on doc of maps
|
|
* richcarl/mnesia-app-module/PR-1223:
Make a separate application module for Mnesia
|
|
* maint:
New commands to ease looking up OTP documentation
|
|
* leoliu/tools/emacs-erldoc/PR-1197/OTP-14018:
New commands to ease looking up OTP documentation
|
|
typo
|
|
|
|
|
|
* kostis/hipe-bs_match_string/PR-1234/OTP-14005:
Add a test case that should now work
Fix the native code translation of bs_match_string
|
|
|
|
* ferd/ssl-allow-ecc-config/PR-1210/OTP-13959:
Add ECC curve selection order config in TLS server
|
|
|
|
* egil/erts/cuddle-tests:
stdlib: Increase timeouts in ets_SUITE
stdlib: Increase timeouts in rand_SUITE
stdlib: Increase timeouts in base64_SUITE
erts: Use cmd on windows for port_SUITE
|
|
|
|
|
|
Remove one unused clause found by dialyzer.
|
|
Removed two matching errors and one unused clause found by dialyzer.
|
|
* valgrind needs lots of time
|
|
* valgrind needs lots of time
|
|
* valgrind needs lots of time
|
|
|
|
|
|
This fixes a HiPE bug reported on erlang-questions on 2/11/2016.
The BEAM to ICode tranaslation of the bs_match_string instruction,
written long ago for binaries (i.e., with byte-sized strings), tried
to do a `clever' translation of even bit-sized strings using a HiPE
primop that took a `Size' argument expressed in *bytes*.
ICode is not really the place to do such a thing, and moreover there
is really no reason for the HiPE primop not to take a Size argument
expressed in *bits* instead. This commit changes the `Size' argument
to be in bits, postpones the translation of the bs_match_string primop
Fixed in a pair-programming/debugging session with @margnus1.
until RTL and does a proper translation using bit-sized quantities there.
|
|
* sverker/kernel-erts-dependency:
kernel: Add lost dependency to erts-8.1
|
|
* gandrade/fmod/PR-1216/OTP-14000:
Add test cases for math:fmod/2 BIF
Support math:fmod/2 BIF on compiler
Add math:fmod/2 BIF
|
|
|
|
|
|
Returns the (floating point) remainder of first argument divided
by second argument.
|
|
As per RFC 4492 Sec 5.1, the preferred order of selection of named
curves is based on client preferences.
Currently, the SSL application only picks entries according to the
absolute order of entries as tracked in a hardcoded list in code.
This patch changes things so that the client-specified order is
preferred. It also allows a mode where the server can be configured to
override the client's preferred order with its own, although the chosen
ECC must still be within both lists.
The configuration is done through the following options:
- `eccs`, shared by clients and servers alike, allows the specification
of the supported named curves, in their preferred order, and may
eventually support more values for explicit primes and so on.
- `honor_ecc_order`, a server-only option, is similar to
`honor_cipher_order` and will, by default let the server pick the
client-preferred ECC, and otherwise pick the server-preferred one.
The default value for `eccs` is the same as before, although the
server-chosen ECC now defaults to the client rather than previous
choice.
A function `ssl:eccs()` has been added that returns the highest
supported ECCs for the library.
|
|
* essen/stdlib/proc_lib-propagate-exceptions/PR-1088/OTP-14001:
Propagate exceptions fully when using proc_lib
|
|
* maint:
Update preloaded
erts: Correct type declaration of match specification head
Conflicts:
erts/preloaded/ebin/erlang.beam
erts/preloaded/ebin/erts_internal.beam
|
|
* hasse/erts/fix_match_spec_head/OTP-13996:
Update preloaded
erts: Correct type declaration of match specification head
|
|
|
|
* roadrunnr/tools/fprof-send-non-exist/PR-1201/OTP-13998:
handle send_to_non_existing_process trace event in fprof
|
|
|
|
* github/pr/1219:
Correct spelling error in ssl_distribution.xml
|
|
|
|
|
|
Bug reported by Peti Gömöri <[email protected]>.
|
|
In OTP-19.1 (c70ca686fe269db6079a2ca1c7e09cdfc0cfa903)
erts_code_purger:finish_after_on_load/2 was added
and called by code_server.erl.
|
|
This makes proc_lib behaves like a normal process as far
as the propagation of exceptions is concerned.
Before this commit, the following difference could be
observed:
6> spawn_link(fun() -> ssl:send(a,b) end).
<0.43.0>
7> flush().
Shell got {'EXIT',<0.43.0>,
{function_clause,
[{ssl,send,[a,b],[{file,"..."},{line,275}]}]}}
ok
8> proc_lib:spawn_link(fun() -> ssl:send(a,b) end).
<0.46.0>
9> flush().
Shell got {'EXIT',<0.46.0>,function_clause}
After this commit, we get the following instead:
3> flush().
Shell got {'EXIT',<0.61.0>,
{function_clause,
[{ssl,send,[a,b],[{file,"..."},{line,275}]},
{proc_lib,init_p,3,[{file,"..."},{line,232}]}]}}
The stacktrace will show minor differences of course
but the form is now the same as without proc_lib.
The rationale behind this commit is that:
* We now have a single form regardless of how the process
was started
* We can use the stacktrace to programmatically alter behavior
(for example an HTTP server identifying problems in input
decoding to send back a generic 400, or a 500 otherwise)
* We can access the stacktrace to print it somewhere (for
example an HTTP server could send it back to the client
when a debug mode is enabled)
|
|
|
|
|
|
|
|
into maint
* legoscia/kernel/clarify-permission-bits/PR-1204/OTP-13991:
Clarify permission bits in file.xml
|
|
|
|
* egil/mnesia/dont-tty-log-nodes:
mnesia: Don't show error_logger messages in tests
|
|
|
|
|
|
|
