unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Taylan Kammer <taylan.kammer@gmail.com>
To: tomas@tuxteam.de, guile-devel@gnu.org
Subject: Re: Request to add *-resize! functions for contiguous mutable data structures.
Date: Sun, 8 Aug 2021 14:17:47 +0200	[thread overview]
Message-ID: <787d4b70-5580-7014-0f54-c9e8ae3d008b@gmail.com> (raw)
In-Reply-To: <20210807211957.GA730@tuxteam.de>

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



  reply	other threads:[~2021-08-08 12:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 14:33 Request to add *-resize! functions for contiguous mutable data structures Vijay Marupudi
2021-08-07 10:31 ` Taylan Kammer
2021-08-07 21:19   ` tomas
2021-08-08 12:17     ` Taylan Kammer [this message]
2021-08-07 11:09 ` Maxime Devos
2021-08-07 17:46   ` Taylan Kammer
2021-08-09  4:02     ` Vijay Marupudi
2021-08-09 18:24       ` Maxime Devos
2021-08-09 18:35         ` Vijay Marupudi

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-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=787d4b70-5580-7014-0f54-c9e8ae3d008b@gmail.com \
    --to=taylan.kammer@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=tomas@tuxteam.de \
    /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).