* The whole options module should be inline
* Use inline per proc and tag `lent` where appropriate
* Remove lent annotation (failing at compiletime)
(cherry picked from commit f71f8b0239)
This let us see the definition of `Callback` in docs, which is required
to even make use of asyncdispatch.
Ref #13539.
(cherry picked from commit 7beed44fc9)
New issue: since `Table[A, B]` allocates its backing storage with
`newSeq[KeyValuePair[A, B]]`, it's no longer legal to create a table
with `not nil` types used as either keys or values.
* new minor feature: macros for proc types, to be documented
* Finished the implementation and added tests
* [skip ci] Describe the new custom pragmas in the manual and the changelog
Co-authored-by: Zahary Karadjov <zahary@gmail.com>
* Unwind just the "pseudorandom probing" (whole hash-code-keyed variable
stride double hashing) part of recent sets & tables changes (which has
still been causing bugs over a month later (e.g., two days ago
https://github.com/nim-lang/Nim/issues/13794) as well as still having
several "figure this out" implementation question comments in them (see
just diffs of this PR).
This topic has been discussed in many places:
https://github.com/nim-lang/Nim/issues/13393https://github.com/nim-lang/Nim/pull/13418https://github.com/nim-lang/Nim/pull/13440https://github.com/nim-lang/Nim/issues/13794
Alternative/non-mandatory stronger integer hashes (or vice-versa opt-in
identity hashes) are a better solution that is more general (no illusion
of one hard-coded sequence solving all problems) while retaining the
virtues of linear probing such as cache obliviousness and age-less tables
under delete-heavy workloads (still untested after a month of this change).
The only real solution for truly adversarial keys is a hash keyed off of
data unobservable to attackers. That all fits better with a few families
of user-pluggable/define-switchable hashes which can be provided in a
separate PR more about `hashes.nim`.
This PR carefully preserves the better (but still hard coded!) probing
of the `intsets` and other recent fixes like `move` annotations, hash
order invariant tests, `intsets.missingOrExcl` fixing, and the move of
`rightSize` into `hashcommon.nim`.
* Fix `data.len` -> `dataLen` problem.
* #13806 - first call sysctl with a null buffer to get the length, then alloc buffer and call again
* Use csize_t rather than csize
* Suggestions from @Clyybber
Co-authored-by: Euan Torano <euan.torano@bluesky-wireless.co.uk>
* osproc: move fork-based code path under the when conditional
* osproc: avoid using the environ global on Haiku
* osenv: import environ from stdlib.h on Haiku
Haiku's environ is declared in `<stdlib.h>` by default, differing from
POSIX and/or Linux. Import it from there to avoid collision with anyone
importing `<stdlib.h>` from Nim.
These constants were defined as `cint`. They can be huge on certain
systems, such as Haiku, and trigger out-of-bounds errors in
asyncdispatch.
Ref #13764.
* make i2d_X509 and d2i_X509 always available
i2d_X509 and d2i_X509 have been available in all versions of OpenSSL, so
make them available even if nimDisableCertificateValidation is set.
* introduce getPeerCertificates, fixes#13299
getPeerCertificates retrieves the verified certificate chain of the peer
we are connected to through an SSL-wrapped Socket/AsyncSocket. This
introduces the new type Certificate which stores a DER-encoded X509 certificate.
* Implement SSL/TLS certificate checking #782
* SSL: Add nimDisableCertificateValidation
Remove NIM_SSL_CERT_VALIDATION env var
tests/untestable/thttpclient_ssl.nim ran successfully on Linux with libssl 1.1.1d
* SSL: update integ test to skip flapping tests
* Revert .travis.yml change
* nimDisableCertificateValidation disable imports
Prevent loading symbols that are not defined on older SSL libs
* SSL: disable verification in net.nim
..when nimDisableCertificateValidation is set
* Update changelog
* Fix peername type
* Add define check for windows
* Disable test on windows
* Add exprimental GitHub action CI for SSL
* Test nimDisableCertificateValidation
According to [RFC7230], the reason phrase attached to the status line is
optional and clients should not rely on it. This in turn causes the proc
to be practically useless, as clients should only inspect the return
code.
Ref #13680.
[RFC7230]: https://tools.ietf.org/html/rfc7230#section-3.1.2
