From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: mmap for guile Date: Tue, 19 Jul 2022 15:30:22 +0200 Message-ID: <5ef0ea89ba3dfe9d4d02e6df6073d89d821e2b43.camel@telenet.be> References: <56ee7537-1666-3d04-7093-732a75624e9b@gmail.com> <0cf4e4ee80169487694b844996e04f3293eab92f.camel@telenet.be> <87k08tfau0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6154"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.42.1 Cc: guile-devel@gnu.org To: Ludovic =?ISO-8859-1?Q?Court=E8s?= , guile-user@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jul 19 15:55:00 2022 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oDngi-0001RC-9o for guile-devel@m.gmane-mx.org; Tue, 19 Jul 2022 15:55:00 +0200 Original-Received: from localhost ([::1]:36752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDngg-0002Wb-S9 for guile-devel@m.gmane-mx.org; Tue, 19 Jul 2022 09:54:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDnJ3-0005si-BQ for guile-devel@gnu.org; Tue, 19 Jul 2022 09:30:33 -0400 Original-Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]:42720) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDnIw-00076J-FN for guile-devel@gnu.org; Tue, 19 Jul 2022 09:30:32 -0400 Original-Received: from ptr-bvsjgyig5nh0salm0pi.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by laurent.telenet-ops.be with bizsmtp id x1WN2700S20ykKC011WPyy; Tue, 19 Jul 2022 15:30:23 +0200 In-Reply-To: <87k08tfau0.fsf@gnu.org> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1658237423; bh=YKnf46rJx6Bkt4el+s27H9AZ3KD5BWiJY1zR83F92zU=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=KSHu3fm7WoaQ+XbKsPWSHxzcDQsE7GDuJCmlvyXrCbNZuf8chOoeRVx0MjbFYvXhk Yvh3J6nKh9m6+4L+sotJZAd4/rBpX1+Jt70vuKwAv9kX58RYtZlz8IQu57D+WmGMYt UW8TDM/3iZ6MCe7t/zfvTfvA6tgWSY55CSvAzi/tkz7NTul+rtMsvtgCQSewm9LgFV MpdcbwLxrKzCy63IwHMo42Qy+cLvO+4dsvRHA2T+Na93tcjXVqfi3tKtZ1PJ6MJM0U qKkCaDfx4r4vblxh8nlH+i8ye9C3MokS2GjSbyGCDMXa2sQG1rarYZtGSAYN1bnfi0 JmjEogIQXEghA== Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:21258 gmane.lisp.guile.user:18431 Archived-At: Ludovic Courtès schreef op ma 04-07-2022 om 12:09 [+0200]: > But we could provide special semantics: the bytevector would become > zero-length (possible, but weird, as Maxime points out), or it would > be turned into a /dev/zero mapping (weird as well). > > Thoughts? The former is weird and can currently cause out-of-bound reads/writes (see the TOCTTOU issue I pointed out). It also would also prevent optimisations (for things like (bytevector-ref bv 9999) (bytevector-ref bv 1), to eliminate some range checks). The latter is weird too, but it's easy to reason about -- the compiler can assume the bytevector length is fixed, so no TOCTTOU issue and possibility of optimisations, user code also doesn't have to worry about changing lengths, no bad interactions with the bytevector->pointer + pointer->bytevector trick to reduce the range of a bytevector ... (except potential GC issues, to which I haven't yet received a response to test for them or resolve them or document limitations). As such, I would recommend the latter. Though if we go for the former, we might as well implement a bytevector-free! (why is there a munmap but not a bytevector-free!). Greetings, Maxime.