Eli Zaretskii <
address@hidden> schrieb am Fr., 20. Nov. 2015 um 10:54 Uhr:
> Re this fragment from module.c:
>
> Lisp_Object ret = list4 (Qlambda,
> list2 (Qand_rest, Qargs),
> documentation ? build_string (documentation) : Qnil,
> list3 (module_call_func,
> envobj,
> Qargs));
>
> Thou shalt not use build_string, except when you _know_ the argument
> will always be a pure-ASCII string. Practically, this means the
> argument must be a constant ASCII string. See these messages (and the
> preceding discussion, if you are interested) for the gory details:
>
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-10/msg00955.html
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-10/msg00976.html
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-10/msg00979.html
>
> The above should call make_multibyte_string instead.
>
>
> We had a discussion about encodings in
> https://github.com/aaptel/emacs-dynamic-module/issues/37. Sorry that this
> didn't get resolved earlier; it's an important point. My suggestion would be to
> always mandate specifying an encoding whenever a char* is passed, and limit
> that to two or three functions dealing with creating strings and accessing
> string contents. Would that address your concerns?
No, this is not about encoding at all. This is about calling
build_string: you should only call it when the argument is a fixed
ASCII string. If the argument is not fixed or might include non-ASCII
characters, you should call make_multibyte_string instead. That's
because build_string might decide on its own whether to produce a
unibyte or a multibyte string, out of your control, whereas we always
want a multibyte string in this context.
build_string doesn't encode or decode its argument, it creates a Lisp
object whose text is taken from the argument. It's similar to
make_number in that respect.
Let me summarize the issues I see: The internal Emacs encoding can change between versions (command in mule-conf.el), therefore we shouldn't use it in the module API. IIUC this rules out make_multibyte_string: it only accepts the internal encoding. Therefore I proposed to always have users specify the encoding explicitly and then use code_convert_string_norecord to create the Lisp string objects. Would that work? (We probably then need another set of functions for unibyte strings.)