Hi Chong Yidong,
"Chong Yidong" writes: > The bug is in the Lisp_Object QUNICODE, which specifies the > "utf-16le-dos" coding system used by `selection-coding-system'. QUINCODE is just a symbol, a unique string. It is used for looking up the actual coding-system. setup_coding_system() in src/coding.c does that lookup by filling in the struct coding_system. > When a coding_system is extracted from QUNICODE, the parameter > coding->spec.ccl.encoder.buf_magnification is 1. This causes a call to > encoding_buffer_size (in convert_to_handle_as_coded, w32select.c:247) to > return a buffer size that is too small for the encoded string. > > I'm guessing the magnification has to be set to 2, because `abc...' > gets encoded to `a\0b\0c\0...' (encoding_buffer_size multiplies this > again by 2, because of the CRLF issue.) That would indicate that the coding-system "utf-16le-dos" itself has a bug. The source code description comment for encoding_buffer_size() says Return maximum size (bytes) of a buffer enough for encoding SRC_BYTES of text to CODING. which matches its usage in w32select.c, I think. > Trouble is, I can't find where the `spec.ccl...', or indeed any of > the other parameters of QUNICODE are initialized. Grep is our friend ;-). The coding-system (and its CCL programs) is created in lisp/international/ccl.el using (define-ccl-program ...). The parameter BUFFER_MAGNIFICATION for that function is set as 1 there for the encoders (ccl-encode-mule-utf-16le, ccl-encode-mule-utf-16be, ccl-encode-mule-utf-16le-with-signature, ccl-encode-mule-utf-16be-with-signature), so that might well be the problem. Can you try and replace that 1 with 2 and see if your problem goes away? benny _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
