[ruby-core:116211] Re: [Ruby master Feature#19057] Hide implementation of `rb_io_t`.

[Eric Wong via ruby-core <ruby-core@ml.ruby-lang.org>]

"ioquatix (Samuel Williams) via ruby-core" <ruby-core@ml.ruby-lang.org> wrote:
> - unicorn has merged a fix but it is not released: https://yhbt.net/unicorn.git/63c85c4282d15e22bd32a905883d2d0e149619d1/s/
> - kgio has merged a fix but it is not released: https://yhbt.net/kgio.git/dbf5290cf9f89174f6b35a597af9a4226633d79b/s/
> - raindrops merged a fix but it is not released: https://yhbt.net/raindrops.git/b3212417cc3e7cc44aa9e1ffe89b0d62ef3fdab5/s/

Still working on writing release notes and docs.
<snip> sharing common struct fields example (more below)

> However, we are not 100% confident this is safe according to
> the C specification. My experience is not sufficiently wide to
> say this is safe in practice, but it does look okay to both
> myself, and @Eregon + @tenderlovemaking have both given some
> kind of approval.
> 
> That being said, maybe it's not safe.

It's safe.  Normal (unpacked) C structs have a well-defined and
stable ABI.  Ruby has been relying on it with RVALUE union and
RBasic->flags for decades.  FFI users all rely on this C ABI
stability for calling C code w/o a C compiler.

gcc and clang have a __transparent_union__ attribute designed
to make migrations like this easy and painless for old code.

rb_io_descriptor also introduces extra function call overhead.
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/