Ragel generates a code `0 <= (*p)` where `*p` is char.
As char is unsigned by default on arm and RISC-V, it is warned by gcc:
```
compiling parser.c
parser.c: In function ‘JSON_parse_string’:
parser.c:1566:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if ( 0 <= (*p) && (*p) <= 31 )
^
parser.c:1596:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if ( 0 <= (*p) && (*p) <= 31 )
^
```
This change removes the warning by substituting the condition with
`0 <= (signed char)(*p)`.
Let's revert the changes for now, as it cannot be included in the 2.2.0
release.
My comment on #257:
> A blocker is OpenSSL::SSL::SSLContext#add_certificate_chain_file. It
> has a pending change and I don't want to include it in an incomplete
> state.
>
> The initial implementation in commit 46e4bdba40c5 was not really
> useful. The issue is described in #305. #309 extended it
> to take the corresponding private key together. However, the new
> implementation was incompatible on Windows and was reverted by #320 to
> the initial one.
>
> (The prerequisite to implement it in) an alternative way is #288, and
> it's still cooking.
This effectively reverts the following commits:
- dacd08937ccd ("ssl: suppress test failure with SSLContext#add_certificate_chain_file", 2020-03-09)
- 46e4bdba40c5 ("Add support for SSL_CTX_use_certificate_chain_file. Fixes #254.", 2019-06-13)
ea925619a9
Implement OpenSSL::PKey::PKey#oid as a wrapper around EVP_PKEY_id().
This allows user code to check the type of a PKey object.
EVP_PKEY can have a pkey type for which we do not provide a dedicated
subclass. In other words, an EVP_PKEY that is not any of {RSA,DSA,DH,EC}
can exist. It is currently not possible to distinguish such a pkey.
Also, implement PKey#inspect to include the key type for convenience.
dafbb1b3e6
Maybe due to e1855100e4, CentOS, RHEL, and
Fedora CIs have started failing with SEGV. Try to avoid
ffi_closure_alloc on those environments.
20200512T183004Z.fail.html.gz
20200512T183004Z.fail.html.gz
20200512T183003Z.fail.html.gz
to define HAVE_FFI_CLOSURE_ALLOC.
The macro is used in closure.c, so have_func check is needed.
If pkg-config is not installed, extconf.rb fails to detect the version
of libffi, and does not add "-DUSE_FFI_CLOSURE_ALLOC=1" even when system
libffi version is >= 3.2.
If USE_FFI_CLOSURE_ALLOC is not defined, closure.c attempts to check if
HAVE_FFI_CLOSURE_ALLOC is defined or not, but have_func was removed with
528a3a1797, so the macro is always not
defined.
This resulted in this deprecation warning:
20200512T123003Z.log.html.gz
```
compiling closure.c
closure.c: In function 'initialize':
closure.c:265:5: warning: 'ffi_prep_closure' is deprecated: use ffi_prep_closure_loc instead [-Wdeprecated-declarations]
265 | result = ffi_prep_closure(pcl, cif, callback, (void *)self);
| ^~~~~~
In file included from ./fiddle.h:42,
from closure.c:1:
/usr/include/x86_64-linux-gnu/ffi.h:334:1: note: declared here
334 | ffi_prep_closure (ffi_closure*,
| ^~~~~~~~~~~~~~~~
```
Currently, Net::HTTP can only send a single SSL certificate when it
establishes a connection. Some use-cases involve sending an entire
certificate chain to the destination; for this, SSLContext supports
assigning to #extra_chain_cert=.
This adds support in Net::HTTP for exposing this underlying SSLContext
property to end-users. [Feature #9758]
