From: Brennan Vincent <brennan@umanwizard.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] Add a mechanism for passing unibyte strings from lisp to modules.
Date: Fri, 21 Jun 2024 16:14:05 -0400 [thread overview]
Message-ID: <225D336D-933E-4CA3-B245-89992D7E6C41@umanwizard.com> (raw)
In-Reply-To: <86v822jeqh.fsf@gnu.org>
> On Jun 21, 2024, at 15:08, Eli Zaretskii <eliz@gnu.org> wrote:
>
>
>>
>> From: Brennan Vincent <brennan@umanwizard.com>
>> Date: Fri, 21 Jun 2024 14:13:14 -0400
>>
>> Since the introduction of make_unibyte_string, it has been possible to pass
>> raw binary data from modules to lisp, but not the other way around
>> (except by using vectors of bytes, which is inefficient). This
>> patch implements that feature so that raw binary data can be sent both ways.
>
> Please describe the motivation and real-life use cases for this.
As far as I know, unibyte strings are the only efficient way to represent arbitrary binary buffers in emacs. If that’s not true, I’d be happy to be corrected.
I think there are many possible cases where module authors will want to communicate binary data, but I’ll just describe one (my own). I’m working on a major mode that reads ELF files (whose contents it stores in a unibyte buffer) and provides various features like disassembling code. To do this it passes chunks of code to a module which in turn passes them to the Capstone disassembly library. To do this without being able to pass unibyte strings, I have to take the string of bytes, expand it to a vector of bytes, pass that to the module, and have the module copy each byte back out in a loop. This is very inefficient.
> In general, we want to minimize the use of unibyte strings in Emacs.
Why? What else should be used instead to represent arbitrary bytes?
>
> I also don't understand the need for unibyte-string-p, since we
> already have multibyte-string-p.
That’s fair, I only added it so I could use it as an argument to CHECK_TYPE.
next prev parent reply other threads:[~2024-06-21 20:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 18:13 [PATCH] Add a mechanism for passing unibyte strings from lisp to modules Brennan Vincent
2024-06-21 18:13 ` Brennan Vincent
2024-06-21 19:08 ` Eli Zaretskii
2024-06-21 20:14 ` Brennan Vincent [this message]
2024-06-22 6:50 ` Eli Zaretskii
[not found] ` <87o77t6lyn.fsf@taipei.mail-host-address-is-not-set>
2024-06-22 16:12 ` Eli Zaretskii
2024-06-23 21:15 ` Andrea Corallo
2024-06-24 11:45 ` Eli Zaretskii
2024-06-25 17:36 ` Brennan Vincent
2024-06-26 12:26 ` Eli Zaretskii
2024-06-26 12:39 ` tomas
2024-06-26 13:23 ` Eli Zaretskii
2024-06-26 13:33 ` tomas
2024-06-26 14:32 ` Brennan Vincent
2024-06-26 15:53 ` Eli Zaretskii
2024-06-26 15:34 ` Eli Zaretskii
2024-06-27 3:36 ` Brennan Vincent
2024-06-27 6:05 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=225D336D-933E-4CA3-B245-89992D7E6C41@umanwizard.com \
--to=brennan@umanwizard.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.