emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add a mechanism for passing unibyte strings from lisp to mod


From: Brennan Vincent
Subject: Re: [PATCH] Add a mechanism for passing unibyte strings from lisp to modules.
Date: Fri, 21 Jun 2024 16:14:05 -0400


> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]