From: Eric Wong via ruby-core <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: Eric Wong <normalperson@yhbt.net>
Subject: [ruby-core:116389] Re: [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
Date: Wed, 24 Jan 2024 01:03:00 +0000 [thread overview]
Message-ID: <20240124010300.M208904@dcvr> (raw)
In-Reply-To: <redmine.journal-106396.20240123134453.3344@ruby-lang.org>
"Eregon (Benoit Daloze) via ruby-core" <ruby-core@ml.ruby-lang.org> wrote:
> I would be more worried about the C compiler, if the C
> compiler figures out a pointer is casted to "unrelated" struct
> types it might consider that as undefined behavior and do
> anything.
It's not undefined, every platform defines its own C ABI.
Any toolchain which ignores that ABI cannot interoperate at all
(which is fine for cases where you don't need interop)
Consider 1) how many languages/runtimes call C libraries.
Now consider 2) how many languages/libraries get called by C.
1 is common, 2 is rare and needs explicit instructions in
the non-C language (e.g. extern "C" in C++ headers).
gcc and clang generate objects from C which can safely be linked
by the others' linker. This isn't true for C++ at all.
FFI is completely dependent on a stable ABI.
> But I suspect that's explicitly not undefined behavior,
> because C has no notion of struct types being related or not,
> and there is likely tons of software using structs
> "inheriting/extending" another smaller struct.
>
> It might not explicitly be allowed either because I guess the
> fully correct way to do this is using a union of both structs,
> and not casting to a specific struct directly then.
FFI and Rust would not be able to use C libraries if the
C toolchain were told to violate its platform ABI.
Consider "struct sockaddr *" use in C standard library:
Functions like accept, connect, bind, getpeername, getsockname,
etc. all take a "struct sockaddr *" arg, but callers are expected
to allocate one of sockaddr_{in,in6,un,storage,...} to call them.
No unions are forced on a user for those sockaddr functions.
(I end up defining unions myself in what little C code I maintain,
but that's my choice for maintainability).
Same for POSIX fcntl locks, various ioctls, getsockopt/setsockopt,
or any other function which takes multiple struct types.
You can use FFI or syscall+pack/unpack on all of those
functions.
To make things more explicit, gcc and clang has
transparent_union which is intended to help document and
preserve ABI compatibility:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Type-Attributes.html#index-transparent_005funion-type-attribute
______________________________________________
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/
next prev parent reply other threads:[~2024-01-24 1:03 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-15 1:54 [ruby-core:110300] [Ruby master Bug#19057] Hide implementation of `rb_io_t` ioquatix (Samuel Williams)
2022-10-15 2:12 ` [ruby-core:110301] " ioquatix (Samuel Williams)
2022-10-15 11:02 ` [ruby-core:110309] " Eregon (Benoit Daloze)
2022-10-17 7:07 ` [ruby-core:110348] " ioquatix (Samuel Williams)
2023-05-27 8:49 ` [ruby-core:113678] [Ruby master Feature#19057] " kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core
2023-05-27 9:58 ` [ruby-core:113680] " Eregon (Benoit Daloze) via ruby-core
2023-05-27 10:12 ` [ruby-core:113681] " ioquatix (Samuel Williams) via ruby-core
2023-05-28 2:19 ` [ruby-core:113689] " ianks (Ian Ker-Seymer) via ruby-core
2023-05-29 9:15 ` [ruby-core:113696] " Eregon (Benoit Daloze) via ruby-core
2023-05-30 1:04 ` [ruby-core:113698] " ioquatix (Samuel Williams) via ruby-core
2023-06-01 0:52 ` [ruby-core:113723] " ioquatix (Samuel Williams) via ruby-core
2023-06-01 9:56 ` [ruby-core:113728] " Eregon (Benoit Daloze) via ruby-core
2023-06-01 11:11 ` [ruby-core:113731] " ioquatix (Samuel Williams) via ruby-core
2023-06-08 2:39 ` [ruby-core:113802] " ioquatix (Samuel Williams) via ruby-core
2023-06-09 8:14 ` [ruby-core:113844] " byroot (Jean Boussier) via ruby-core
2023-06-09 8:33 ` [ruby-core:113845] " ioquatix (Samuel Williams) via ruby-core
2023-06-23 10:36 ` [ruby-core:114014] " kamil-gwozdz via ruby-core
2023-07-07 0:41 ` [ruby-core:114104] " k0kubun (Takashi Kokubun) via ruby-core
2023-07-07 2:04 ` [ruby-core:114106] " nobu (Nobuyoshi Nakada) via ruby-core
2023-07-26 22:23 ` [ruby-core:114298] " k0kubun (Takashi Kokubun) via ruby-core
2023-08-24 13:41 ` [ruby-core:114491] " ioquatix (Samuel Williams) via ruby-core
2023-08-25 1:07 ` [ruby-core:114521] " naruse (Yui NARUSE) via ruby-core
2023-08-25 1:43 ` [ruby-core:114522] " ioquatix (Samuel Williams) via ruby-core
2023-09-05 9:24 ` [ruby-core:114627] " byroot (Jean Boussier) via ruby-core
2024-01-14 3:20 ` [ruby-core:116197] " ioquatix (Samuel Williams) via ruby-core
2024-01-14 3:30 ` [ruby-core:116198] " ioquatix (Samuel Williams) via ruby-core
2024-01-15 3:23 ` [ruby-core:116211] " Eric Wong via ruby-core
2024-01-15 5:49 ` [ruby-core:116213] " ioquatix (Samuel Williams) via ruby-core
2024-01-23 12:56 ` [ruby-core:116377] " Eric Wong via ruby-core
2024-01-23 13:44 ` [ruby-core:116379] " Eregon (Benoit Daloze) via ruby-core
2024-01-24 1:03 ` Eric Wong via ruby-core [this message]
2024-03-18 1:58 ` [ruby-core:117204] " mame (Yusuke Endoh) via ruby-core
2024-03-18 5:22 ` [ruby-core:117206] " ioquatix (Samuel Williams) via ruby-core
2024-03-18 7:43 ` [ruby-core:117207] " byroot (Jean Boussier) via ruby-core
2024-03-18 8:03 ` [ruby-core:117208] " ioquatix (Samuel Williams) via ruby-core
2024-03-19 2:35 ` [ruby-core:117220] " mame (Yusuke Endoh) via ruby-core
2024-03-23 18:23 ` [ruby-core:117298] " Eric Wong via ruby-core
2024-03-19 3:07 ` [ruby-core:117224] " matz (Yukihiro Matsumoto) via ruby-core
2024-03-19 9:33 ` [ruby-core:117226] " ioquatix (Samuel Williams) via ruby-core
2024-03-19 10:56 ` [ruby-core:117228] " ioquatix (Samuel Williams) via ruby-core
2024-03-19 11:44 ` [ruby-core:117229] " Eregon (Benoit Daloze) via ruby-core
2024-03-19 12:33 ` [ruby-core:117230] " ioquatix (Samuel Williams) via ruby-core
2024-03-20 13:02 ` [ruby-core:117262] " mame (Yusuke Endoh) via ruby-core
2024-03-20 18:40 ` [ruby-core:117267] " Eregon (Benoit Daloze) via ruby-core
2024-03-22 2:28 ` [ruby-core:117289] " ioquatix (Samuel Williams) via ruby-core
2024-03-22 3:55 ` [ruby-core:117290] " k0kubun (Takashi Kokubun) via ruby-core
2024-03-23 21:49 ` [ruby-core:117300] " ioquatix (Samuel Williams) via ruby-core
2024-03-28 8:32 ` [ruby-core:117361] " Eric Wong via ruby-core
2024-03-24 4:45 ` [ruby-core:117301] " mame (Yusuke Endoh) via ruby-core
2024-03-25 8:28 ` [ruby-core:117310] " byroot (Jean Boussier) via ruby-core
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240124010300.M208904@dcvr \
--to=ruby-core@ruby-lang.org \
--cc=normalperson@yhbt.net \
--cc=ruby-core@ml.ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).