From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 341001F542 for ; Fri, 9 Jun 2023 08:34:05 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=jOaxZABL; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=EDZhHO2z; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 342CA7F8EA; Fri, 9 Jun 2023 08:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1686299637; bh=ABrzLIBTbaN9aP7ZvuGFWwe7ONGTVBXXsNUGkAJ/HMc=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=jOaxZABLSVGnXanDny4favXtwf5dXQIzcjDJlU5QqEldRWF6OvIAToRskoKjP1hxd n0QmNg3m//NOI05aXVoUQByoR2UYIgSGcQDT9U08F9WjF72Ikml5vc7Zfz9DNYpUr1 rpkkkHt/Kn1746zwSiG5ZcuwNaekynciaOYeQDZ0= Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 45D037F8E8 for ; Fri, 9 Jun 2023 08:33:54 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=EDZhHO2z; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=JmTzFUdKMN5gjwV2e/pPsiHG9SZ1Khm3zf94BjCJtpE=; b=EDZhHO2zdYvVHVF49KF397m35/xuQy83X9D8Cux5enoUMLfjXg9anDOv4UjBExWXns6e McyUsuthge0Bx93koDGmLj7Pxfgi8A9bxOimkZlzb5o0+NJxfs1I+wJ3ofONwL70ffz7VC WFRUpsC/X3S720jhnR15Q3Hqh5SmSUecvoOjoPKDnHV00gX2MMoErKZqLvrBmCbhktw4D4 eY9BE8uUFukOWWJT4l5L5j/KfBbCbFoEQEY4x2/hyC22O52AUbR/3H5f9XrLc5M11OlR0U fRx/+DfdXYyovOLGlN9VRIWYr3hj2R23WSn2UthMNin+cMqEPLc/XyJrbdUAnezg== Received: by filterdrecv-65f68489c8-xfp5j with SMTP id filterdrecv-65f68489c8-xfp5j-1-6482E3F0-A 2023-06-09 08:33:52.224052056 +0000 UTC m=+2537870.830002207 Received: from herokuapp.com (unknown) by geopod-ismtpd-22 (SG) with ESMTP id 7t3d8GRgSwqvDyWQTpgLjw for ; Fri, 09 Jun 2023 08:33:52.161 +0000 (UTC) Date: Fri, 09 Jun 2023 08:33:52 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 19057 X-Redmine-Issue-Author: ioquatix X-Redmine-Issue-Assignee: ioquatix X-Redmine-Sender: ioquatix X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 90312 X-SG-EID: =?us-ascii?Q?RXGrw3WrKfUduNFRrzMMcXYHKEABJI9T84jNjq2g6rBTg=2FXhHIicnPoJUXLutJ?= =?us-ascii?Q?tdNFg7BiEDMUtMCwjaLtb0ItKeRyv3NlZm6AYiJ?= =?us-ascii?Q?s0JX4Mo6jceLSNI+UwrxMpLrcMV1VHCaKnw3wZy?= =?us-ascii?Q?0L9BjdIdpbWgtOPHZuI+76yDpKAy2C1EKaQQc7t?= =?us-ascii?Q?IustKeMpJvdn=2FMxsVLqavNxhHof5bZVomkJ0V9M?= =?us-ascii?Q?dH398ptmMOgldqocGiQ6c4sVPwK9dHzaxCpbzaT?= =?us-ascii?Q?uZYba+6IWzrJwjUod+xew=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== Message-ID-Hash: FM4YOOEV7VOVPYSIZY6JGJ32TCHLLGWU X-Message-ID-Hash: FM4YOOEV7VOVPYSIZY6JGJ32TCHLLGWU X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:113845] [Ruby master Feature#19057] Hide implementation of `rb_io_t`. List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "ioquatix (Samuel Williams) via ruby-core" Cc: "ioquatix (Samuel Williams)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #19057 has been updated by ioquatix (Samuel Williams). Thanks for the report, fixed in https://github.com/ioquatix/raindrops/commit/94dbdd94977d895f98c084d0ca31c2b9cf0d25d3 ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-103493 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- In order to make improvements to the IO implementation like , we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` 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. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/ ______________________________________________ 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/