Re: Fcall_process: wrong conversion

[Kenichi Handa <handa@m17n.org>]

In article <BAY112-F7409CF46063B56C37BE1ADAA00@phx.gbl>, "Herbert Euler" <herberteuler@hotmail.com> writes:

> `CODING_REQUIRE_ENCODING' test the following things (line 491 to 496,
> coding.h):

> /* Return 1 if the coding context CODING requires code conversion on
>    encoding.  */
> #define CODING_REQUIRE_ENCODING(coding)				\
>   ((coding)->src_multibyte					\
>    || (coding)->common_flags & CODING_REQUIRE_ENCODING_MASK	\
>    || (coding)->mode & CODING_MODE_SELECTIVE_DISPLAY)

That is to make it possible to do encoding of unibyte
string/buffer generated by string-as-unibyte or
(set-buffer-multibyte nil) from multibyte string/buffer.
Perhaps we should not allow such an operation, but as this
feature is there for long, it seems dangerous to change it
now.

How about disabling encoding only for process arguments if
they are already unibyte?  I think such a change is very
safe.

> And there is another problem: if `locale-coding-system' is UTF-16, is
> it correct to add prefix "\377\376" or "\376\377" to every command
> argument?  If not, the current code of `call-process' is wrong, since
> it will always add the prefix.

I think there's no locale that uses utf-16, and it's
impossible to support such a locale because most of basic
libc functions that accept a filename require that it is
terminated by NULL.

---
Kenichi Handa
handa@m17n.org