According to the C99 specification section 7.20.3.2 paragraph 2:
> If ptr is a null pointer, no action occurs.
So we do not need to check that the pointer is a null pointer.
The following script leaks memory in Ripper:
```ruby
require "ripper"
20.times do
100_000.times do
Ripper.parse("")
end
puts `ps -o rss= -p #{$$}`
end
```
(https://github.com/ruby/fiddle/pull/123)
This commit adds two new methods, `Fiddle::Pointer.read` and
`Fiddle::Pointer.write`. Both methods take an address, and will read or
write bytes at that address respectively.
For example we can read from an address without making a Pointer object:
```ruby
Fiddle::Pointer.read(address, 5) # read 5 bytes
```
We can also write to an address without allocating a Pointer object:
```ruby
Fiddle::Pointer.write(address, "bytes") # write 5 bytes
```
This allows us to read / write memory at arbitrary addresses without
instantiating a new `Fiddle::Pointer` object.
Examples where this API would be useful
[1](f03481d28b/lib/tenderjit/fiddle_hacks.rb (L26-L28))
[2](77c8daa2d4/lib/ruby_vm/rjit/c_pointer.rb (L193))
[3](77c8daa2d4/lib/ruby_vm/rjit/c_pointer.rb (L284))
I also added a writer method for the same reasons as the reader.
---------
https://github.com/ruby/fiddle/commit/04238cefed
Co-authored-by: Sutou Kouhei <kou@clear-code.com>
clang generates a warning:
../../../../ext/openssl/ossl_pkey.c:326:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
arg->interrupted = 1;
^ ~
1 error generated.
https://github.com/ruby/openssl/commit/4b2ba7b022
RUBY_OPENSSL_EXTCFLAGS and RUBY_OPENSSL_EXTLDFLAGS have been added for
the primary purpose of appending custom warning flags during
development and CI.
Since checking programs generated by mkmf may not be completely
warning-free, we don't want to apply -Werror that may be supplied from
those environment variables.
https://github.com/ruby/openssl/commit/2a95b971d5
This commit is a workaround to avoid the error below that the
`OpenSSL::PKey.read` fails with the OpenSSL 3.0 FIPS mode.
```
$ openssl genrsa -out key.pem 4096
$ ruby -e "require 'openssl'; OpenSSL::PKey.read(File.read('key.pem'))"
-e:1:in `read': Could not parse PKey (OpenSSL::PKey::PKeyError)
from -e:1:in `<main>'
```
The root cause is on the OpenSSL side. The `OSSL_DECODER_CTX_set_selection`
doesn't apply the selection value properly if there are multiple providers, and
a provider (e.g. "base" provider) handles the decoder implementation, and
another provider (e.g. "fips" provider) handles the keys.
The workaround is to create `OSSL_DECODER_CTX` variable each time without using
the `OSSL_DECODER_CTX_set_selection`.
https://github.com/ruby/openssl/commit/5ff4a31621
The vast majority have no reference so it's just a matter of setting the flags.
For the couple exception, they have very little references so it's
easy.
https://github.com/ruby/openssl/commit/2c7c6de69e
According to the `mkmf.rb#init_mkmf`, there are command line options below.
* `--with-cflags` to set the `cflags`
* `--with-ldflags` to set the `ldflags`
For example the following command compiles with the specified flags. Note that
`MAKEFLAGS` is to print the compiler command lines.
```
$ MAKEFLAGS="V=1" \
bundle exec rake compile -- \
--with-cflags="-Wundef -Werror" \
--with-ldflags="-fstack-protector"
```
However, I couldn't find command line options to append the flags. And this
commit is to append the `cflags` and `ldflags` by the environment variables.
```
$ MAKEFLAGS="V=1" \
RUBY_OPENSSL_EXTCFLAGS="-Wundef -Werror" \
RUBY_OPENSSL_EXTLDFLAGS="-fstack-protector" \
bundle exec rake compile
```
https://github.com/ruby/openssl/commit/b551eb86f6
Introduce Universal Parser mode for the parser.
This commit includes these changes:
* Introduce `UNIVERSAL_PARSER` macro. All of CRuby related functions
are passed via `struct rb_parser_config_struct` when this macro is enabled.
* Add CI task with 'cppflags=-DUNIVERSAL_PARSER' for ubuntu.
* Unify length field for embedded and heap strings
The length field is of the same type and position in RString for both
embedded and heap allocated strings, so we can unify it.
* Remove RSTRING_EMBED_LEN
This reverts commit 10621f7cb9.
This was reverted because the gc integrity build started failing. We
have figured out a fix so I'm reopening the PR.
Original commit message:
Fix cvar caching when class is cloned
The class variable cache that was added in
ruby#4544 changed the behavior of class
variables on cloned classes. As reported when a class is cloned AND a
class variable was set, and the class variable was read from the
original class, reading a class variable from the cloned class would
return the value from the original class.
This was happening because the IC (inline cache) is stored on the ISEQ
which is shared between the original and cloned class, therefore they
share the cache too.
To fix this we are now storing the `cref` in the cache so that we can
check if it's equal to the current `cref`. If it's different we don't
want to read from the cache. If it's the same we do. Cloned classes
don't share the same cref with their original class.
This will need to be backported to 3.1 in addition to 3.2 since the bug
exists in both versions.
We also added a marking function which was missing.
Fixes [Bug #19379]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
The class variable cache that was added in
https://github.com/ruby/ruby/pull/4544 changed the behavior of class
variables on cloned classes. As reported when a class is cloned AND a
class variable was set, and the class variable was read from the
original class, reading a class variable from the cloned class would
return the value from the original class.
This was happening because the IC (inline cache) is stored on the ISEQ
which is shared between the original and cloned class, therefore they
share the cache too.
To fix this we are now storing the `cref` in the cache so that we can
check if it's equal to the current `cref`. If it's different we don't
want to read from the cache. If it's the same we do. Cloned classes
don't share the same cref with their original class.
This will need to be backported to 3.1 in addition to 3.2 since the bug
exists in both versions.
We also added a marking function which was missing.
Fixes [Bug #19379]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
This reverts commit 35da41b29b.
This updates `io-console` to avoid accessing the internal details of `rb_io_t`
and instead use `rb_io_descriptor` and `rb_io_path` etc.
* Add rb_io_path and rb_io_open_descriptor.
* Use rb_io_open_descriptor to create PTY objects
* Rename FMODE_PREP -> FMODE_EXTERNAL and expose it
FMODE_PREP I believe refers to the concept of a "pre-prepared" file, but
FMODE_EXTERNAL is clearer about what the file descriptor represents and
aligns with language in the IO::Buffer module.
* Ensure that rb_io_open_descriptor closes the FD if it fails
If FMODE_EXTERNAL is not set, then it's guaranteed that Ruby will be
responsible for closing your file, eventually, if you pass it to
rb_io_open_descriptor, even if it raises an exception.
* Rename IS_EXTERNAL_FD -> RUBY_IO_EXTERNAL_P
* Expose `rb_io_closed_p`.
* Add `rb_io_mode` to get IO mode.
---------
Co-authored-by: KJ Tsanaktsidis <ktsanaktsidis@zendesk.com>
Nobuyoshi Nakada
yui-knk
cryptogopher
Hiroshi SHIBATA
Peter Zhu
Jean byroot Boussier
Sutou Kouhei
Aaron Patterson
qwyng
Kazuki Yamaguchi
Jun Aruga
Jean Boussier
Samuel Williams
eileencodes
NARUSE, Yui
Benoit Daloze