From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Add 'bytevector-slice'. Date: Fri, 13 Jan 2023 12:32:50 +0100 Message-ID: <87358eekkd.fsf@gnu.org> References: <20230111150015.10219-1-ludo@gnu.org> <57a2d974-0278-409c-678a-6daf7672ba81@telenet.be> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27059"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cc: guile-devel@gnu.org, Andy Wingo To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Jan 13 12:33:31 2023 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 1pGIJO-0006e3-OS for guile-devel@m.gmane-mx.org; Fri, 13 Jan 2023 12:33:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGIIy-00046R-6C; Fri, 13 Jan 2023 06:33:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGIIr-000460-Ql for guile-devel@gnu.org; Fri, 13 Jan 2023 06:33:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGIIq-0001gY-Eh; Fri, 13 Jan 2023 06:32:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=woaxVEvLFUFzi6qVHSy34MHdEZ7YRELKJq97VbmAmIw=; b=lPeQOJ0bplq4Jy1Cuoyd dJgK1TyPRu6tOZ8TnaVnc06weyjQA8SdbjxBQURd9Gp2ku8HS3p2UffKtOvqXqlWcVO5fSdmSYV/Z et/hm+8UWdQGUuYWmKkyAeZs7PDg/PwWw9oQWpoxb+f9AVolApZAcZMr5QMrV1L8DTLtqfHjjr2dI yRTEIIOmQvq8tCrMZ91mo710fko5jlMR/wPDn8I7e+NcaIaSHyVs8dhgpiqbuUhdLRKvqAUrrI+be VLR1QiSZ1mbRUhBoGGhbnKSNd7zg29POVNDKOftnboQng/h1MF2lTeuzobxnZ8zVVVZv0CAZ+QaCu UoBLkTTNndmZTg==; Original-Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGIIn-00070l-EI; Fri, 13 Jan 2023 06:32:56 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Quartidi 24 =?utf-8?Q?Niv=C3=B4se?= an 231 de la =?utf-8?Q?R=C3=A9volution=2C?= jour du Cuivre X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu In-Reply-To: <57a2d974-0278-409c-678a-6daf7672ba81@telenet.be> (Maxime Devos's message of "Thu, 12 Jan 2023 01:10:57 +0100") 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-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21573 Archived-At: Hi, Maxime Devos skribis: > The only thing missing for me, is a procedure > 'bytevector-slice/read-only' and 'bytevector-slice/write-only', then I > could throw the module implementing the wrapping in Scheme-GNUnet and > the overhead incurred by wrapping away. I did consider the read-only part, but it=E2=80=99s not really implementable currently as SCM_F_BYTEVECTOR_IMMUTABLE flag is even ignored by instructions, and fixing it is far beyond the scope of this patch: https://issues.guix.gnu.org/60779 > On 11-01-2023 16:00, Ludovic Court=C3=A8s wrote: [...] >> +(use-modules (rnrs bytevectors) >> + (rnrs bytevectors gnu)) > > I thought that R6RS reserved (rnrs ...) to the RnRS process, so I > would think that naming it (rnrs bytevectors gnu) would be > standards-incompliant, though I cannot find in the specification, so > maybe it isn't actually reserved. > > (SRFI looks a bit looser to me, so I find the (srfi ... gnu) > acceptable, but (rnrs ... gnu) looks weird to me, I would propose > (ice-9 bytevector-extensions) or such.). I=E2=80=99ll stick to gnu.scm because that=E2=80=99s the convention we=E2= =80=99ve used for extensions so far, and =E2=80=9Cgnu=E2=80=9D is arguably =E2=80=9Creserved= =E2=80=9D. >> +Copyright (C) 1996-1997, 2000-2005, 2009-2023 Free Software Foundation, > > > Where does this year 2022 come from? Does a previous version of this > patch predate the new year? I started working on it in December and my =E2=80=98write-file-hooks=E2=80= =99 updated it. >> + c_offset =3D scm_to_size_t (offset); >> + >> + if (SCM_UNBNDP (size)) >> + { >> + if (c_offset < SCM_BYTEVECTOR_LENGTH (bv)) >> + c_size =3D SCM_BYTEVECTOR_LENGTH (bv) - c_offset; >> + else >> + c_size =3D 0; > + } >> + else >> + c_size =3D scm_to_size_t (size); >> + >> + if (c_offset + c_size > SCM_BYTEVECTOR_LENGTH (bv)) >> + scm_out_of_range (FUNC_NAME, offset); > > > If offset=3DSIZE_MAX-1 and size=3D1, this will overflow to 0 and hence not > trigger the error reporting. This bounds check needs to be rewritten, > with corresponding additional tests. OK. > IIUC, if you use bytevector-slice iteratively, say: > > (let loop ((bv some-initial-value) > (n large-number)) > (if (> n 0) > (loop (bytevector-slice bv 0 (bytevector-length bv)) > (- n 1)) > bv)) > > you will end up with a bytevector containing a reference to a > bytevector containing a reference to ... containing a reference to the > original reference, in a chain of length =E2=89=83 large-number. The =E2=80=98parent=E2=80=99 word is here just so the backing memory isn=E2= =80=99t reclaimed while the slice is still alive. Whether there=E2=80=99s a long chain of =E2=80=98parent=E2=80=99 links or n= ot makes no difference to GC performance nor to memory usage. > Do you know what this 'parent' field even is for? Going by some > comments in 'libguile/bytevectors.c', it is for GC reasons, but going > by the existence of the 'bytevector->pointer' + 'pointer->bytevector' > trick which destroys 'parent' information, it seems unnecessary to me. Like I wrote, it was introduced to keep backing memory alive, generally. With =E2=80=98pointer->bytevector=E2=80=99, we want to make sure the origin= al pointer remains live as long as the bytevector is live (pointer objects can have a finalizer, and that finalizer must not run while the bytevector is live). > Nowadays a https://.../ instead of a mail address, is more > conventional and useful, I'd think. Its even used in old files, > e.g. libguile/r6rs-ports.c. Noted. > A test is missing for the case where the size is unaligned instead of > the offset. Noted. I=E2=80=99ll come up with a second version taking this into account. Thanks! Ludo=E2=80=99.