The dependency of extconf.h on bigdecimal.gemspec does not make sense
as far as no rule is defined for it. Also, the relationship between
extension library and gemspec file is various in default gems, and
does not work well.
7f99b28552
* remove false call-seq (output from Ruby parsing is cleaner)
* explain output: argument in plain words
* change parameter name in docs of #dump_shapes (typo)
JRuby currently ships its own internal bigdecimal extension as
part of the core libraries. In order for users to be able to add
bigdecimal to their Gemfile or gem dependencies, we need to stub
out the C extension and just load the extension shipped with
JRuby.
In the future we will try to move our BigDecimal implementation
into the gem, but for now this is the simplest way to make it
installable on JRuby.
See #169829956c643
Right now the attached object is stored as an instance variable
and all the call sites that either get or set it have to know how it's
stored.
It's preferable to hide this implementation detail behind accessors
so that it is easier to change how it's stored.
This version primarily updates the JRuby extension to use
SnakeYAML Engine, a newer version of the SnakeYAML library, which
also updates YAML support to 1.2. The JRuby extension now also
exposes settings for the parser.
6f2b16b343
See jruby/jruby#7570 for some of the justification for this move. We only
require the parser from SnakeYAML, but in the original form it is
encumbered with Java object serialization code that keeps getting
flagged as a CVE risk. We disagree with the assessment, at least
as it pertains to JRuby (we do not use the code in question) but
our inclusion of the library continues to get flagged by auditing
tools.
This commit starts the process of moving to the successor library,
SnakeYAML Engine. The parser API is largely unchanged, except as
seen in this commit. No Java exceptions are thrown, but a number
of Psych tests fail (possibly due to Engine being YAML 1.2 only).
possible
(https://github.com/ruby/fiddle/pull/120)
WG14 N2350 made very clear that it is an UB having type definitions
within "offsetof" [1]. This patch enhances the implementation of macro
ALIGN_OF to use builtin "_Alignof" to avoid undefined behavior when
using std=c11 or newer
clang 16+ has started to flag this [2]
Fixes build when using -std >= gnu11 and using clang16+
Older compilers gcc < 4.9 or clang < 8 has buggy _Alignof even though it
may support C11, exclude those compiler versions
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
[2] https://reviews.llvm.org/D133574
Signed-off-by: Khem Raj <raj.khem@gmail.com>
ad6c9aa826
(https://github.com/ruby/fiddle/pull/119)
The documentation for `Fiddle.dlwrap` and `Fiddle.dlunwrap` were not
very accurate and pretty confusing. This commit updates the
documentation so it's easier to understand what the methods do.
Ref: https://github.com/ruby/psych/pull/495
That's how it works for `safe_load`:
```ruby
>> YAML.safe_load(':foo', permitted_classes: [Symbol])
=> :foo
```
So `safe_dump` should mirror that.
592a75a656
ObjectSpace.trace_object_allocations_start could crash since it adds a
TracePoint for when objects are freed. However, TracePoint could crash
since it modifies st tables while inside the GC that is trying to free
the object. This could cause a memory allocation to happen which would
crash if it triggers another GC.
See a crash log: http://ci.rvm.jp/results/trunk@ruby-sp1/4373707
(https://github.com/ruby/fiddle/pull/118)
String#unpack1 is available since Ruby 2.4, and support for older than
Ruby 2.5 was dropped by #85.
Also simplified a common return statement.
