all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.




  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.