Comment 13 for bug 671923

I appreciate the effort, but this patch cannot be correct.

First of all, the documentation for XLookupString clearly says, "the KeySym is mapped, if possible, to an ISO Latin-1 character or (if the Control modifier is on) to an ASCII control character".

In other words, XLookupString only works on Latin1 single-byte characters.

You seem to be in an environment where XLookupString is returning 4-byte characters that also happen to be Unicode. I see no documentation to suggest that A) this can ever happen, or B) if it did happen, that those bytes would be Unicode! Unless you can find some documentation to this effect, I cannot depend on this behavior in XScreenSaver.

And this, especially, is wrong:

> /* Bytes with bitmask 10xxxxxx are aditional bytes, search for first byte of character */

Bytes with 10 as their highest two bits are perfectly valid Latin1 characters, ranging from A0 (nonbreaking space) through BF (inverted question-mark), and including many common symbols like "copyright", "paragraph", and "1/4".

I suspect the "right" way to fix this is to use XwcLookupString(), which returns a wchar_t, instead of XLookupString(), but I couldn't begin to guess how I take the wchar_t* array and convert it into something that I can stick in a pam_response structure and have it work. (Or, even worse, run it through crypt() and compare it to what's in /etc/passwd.)

In summary: I'm glad you found a way to make it work on your particular computer, with your particular set of environment variable settings, but until someone shows me a theory of operation explaining why this should work at all, I can't use this code.

Thanks...