dv> Jan Vroonhof writes: Jan> Judging from some grepping through the source. The data should probably Jan> be converted into file-name-coding-system, using Jan> GET_C_STRING_FILENAME_DATA_ALLOCA (defined in buffer.h [1]) dv> You're right, this corrects the bug. This brings me a question that dv> might be stupid, but isn't it likely that most use of XSTRING_DATA through the dv> code will be bogus in the same fashion[1]? And what about if we don't know dv> about the coding system ? I mean take the same function, unix_create_process, dv> where the environement is massively copied for the child to be forked. What dv> should we do about it ? Conversion between internal and external string representation needs to happen whenever data is passed between XEmacs and the `outside world'. It sounds like the data in the lisp string may already have been corrupt. if ERROR_CHECK_BUFPOS and MULE are both defined, then any attempt to create a corrupt string should coredump in make_string, pinpointing the true culprit in the C code. I don't know offhand whether any similar error checking is available for buffer text. Martin /* Take some raw memory, which MUST already be in internal format, and package it up into a Lisp string. */ Lisp_Object make_string (CONST Bufbyte *contents, Bytecount length) { Lisp_Object val; /* Make sure we find out about bad make_string's when they happen */ #if defined (ERROR_CHECK_BUFPOS) && defined (MULE) bytecount_to_charcount (contents, length); /* Just for the assertions */ #endif val = make_uninit_string (length); memcpy (XSTRING_DATA (val), contents, length); return val; }