From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Taylan Kammer Newsgroups: gmane.lisp.guile.devel Subject: Re: Request to add *-resize! functions for contiguous mutable data structures. Date: Sun, 8 Aug 2021 14:17:47 +0200 Message-ID: <787d4b70-5580-7014-0f54-c9e8ae3d008b@gmail.com> References: <97e4262b-3ff9-1b21-35d8-45ad9d45ca99@gatech.edu> <5de0d09e-263a-20e3-a0d0-7868593db585@gmail.com> <20210807211957.GA730@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24332"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 To: tomas@tuxteam.de, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sun Aug 08 14:18:09 2021 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 1mChkn-00069X-DQ for guile-devel@m.gmane-mx.org; Sun, 08 Aug 2021 14:18:09 +0200 Original-Received: from localhost ([::1]:48940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mChkm-0000ZL-3Z for guile-devel@m.gmane-mx.org; Sun, 08 Aug 2021 08:18:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56320) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mChka-0000Yl-0E for guile-devel@gnu.org; Sun, 08 Aug 2021 08:17:56 -0400 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:38885) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mChkY-0003QI-5G for guile-devel@gnu.org; Sun, 08 Aug 2021 08:17:55 -0400 Original-Received: by mail-wr1-x433.google.com with SMTP id l18so17545153wrv.5 for ; Sun, 08 Aug 2021 05:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=J2otJaa8LhxSE9cOywEgascorv5vkebY+Pyi5WbxM3o=; b=eb2STZt6PsrO7GQ/FwiwIqs9aYBY5rPjpAxuFrTbUJtbRM7S2+56VoyVopY3yPSFCx qaPMA5lTJlAIfEpsDHL2CVDH7mMJmNUPhH9N+WlP7YLBxdvE2yysnoF117kr6Vdmt3a1 +By6P//cSd2fRTujhCBaCrjtadKhGJ6XMzUh0ToTsK8vy1HrQUyGOQ9eXxatk9J8ZzC/ Dn8LF3nY5VpOwUh8o4dfelu1wSOTgdSP6vpWATNxGh5a9Xg15hKlmXISYQZhKVUnojwf hRNtNRvu57TV6CTU8+e9j7HiI5uIS3sq7LsljGrYAAcunDfKwn0ZaHmHIjtzwDx4ka5o snQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=J2otJaa8LhxSE9cOywEgascorv5vkebY+Pyi5WbxM3o=; b=aduapSX4VAfgcRHT0PNa6cDxB5wG7qqVQX108kHKfoo8sobSkglEHfEzUbBa26Z9kX 4O3aed51wIDBqaMIWdlX0Isc3wRAlgBz+oP6f+vih6buGJrc8VJiWmXk0kgwhG0gOWlZ Bq0hvOzv5eqkbq9gciUQQTEP3uet4hW1SY+N6Zc2vt6nmVbN+qeKTi12s6KNyOB6jBxp GZjCRFUfE+Q+G99gPbYaDP5wduq1vyAEWbZ1HDbF5ET/ojiT7UN0T5iWbiCmtvuMtc+q DT2u+8LE8bsd1RWDr4xf9wmjM3iwXq1DshiWrVJLTgAv1VHgNuihLGENrYoUj6ZGwVzF MU3A== X-Gm-Message-State: AOAM532RbzOWitHFrZtCOUfwU/OUkKAksqdpQmq6bTnB5btIG6e0QibE w/5MddBn5UwDKriUyMN0QdtOVXjBr+I= X-Google-Smtp-Source: ABdhPJxtQuS9nL8msgf+Herbw5IvXBbGY+9k2Y/AQMULrAEjIdSYPAMrv6DEa8X6PheityUNoxFsbA== X-Received: by 2002:a5d:518a:: with SMTP id k10mr19783742wrv.400.1628425071698; Sun, 08 Aug 2021 05:17:51 -0700 (PDT) Original-Received: from [192.168.178.20] (b2b-109-90-125-150.unitymedia.biz. [109.90.125.150]) by smtp.gmail.com with ESMTPSA id q14sm15210492wrs.8.2021.08.08.05.17.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Aug 2021 05:17:51 -0700 (PDT) In-Reply-To: <20210807211957.GA730@tuxteam.de> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=taylan.kammer@gmail.com; helo=mail-wr1-x433.google.com 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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:20821 Archived-At: On 07.08.2021 23:19, tomas@tuxteam.de wrote: > On Sat, Aug 07, 2021 at 12:31:09PM +0200, Taylan Kammer wrote: >> One consideration is how this should behave in the case of >> bytevectors that were created from an FFI pointer [...] > > Hm. I don't understand. Realloc /may/ return a different pointer > from the one it receives, for example if there isn't enough > room "beyond" the currently allocated. It will copy over the > contents, but if someone is holding a pointer to the old area > (as I understand you, this will be the case with an FFI pointer), > this isn't going to end well... > > And then there is the constraint that the (original) pointer > passed to realloc /must/ be one returned by one of the malloc > family (how would the allocator know the original size otherwise?) Bytevectors created from FFI pointers definitely have to be specially handled so as not to call realloc() on the original pointer. There are two ways bytevector-resize! could work in this case: 1. If the requested size is less than or equal to the current size, merely change the size information of the bytevector. Otherwise, return an entirely new bytevector that doesn't point to the original location anymore. This is the "safe" variant. 2. Always just change the size information of the bytevector. This is unsafe because providing a larger size might mean that the bytevector starts allowing access to unallocated memory. But it's not any less safe than the original pointer->bytevector operation where you already provided the size information yourself. The second behavior would help with this issue: https://github.com/TaylanUB/scheme-bytestructures/issues/41 -- Taylan