> I don't think it is so confusing since I think strncpy() expects ASCII > characters,
No. strncpy() expects C chars, half of which are not even in ASCII! In other words bytes. It doesn't care at all whether the bytes represent ASCII, EBCDIC, or whatever. strncpy() works fine for C strings that represent text in whatever multi-byte codeset (as long as it lacks zero bytes), like UTF-8, Microsoft's double-byte codepages, etc. (Well, I exaggerate, obviously if you want to be sure that multi-byte characters don't get truncated you shouldn't use strncpy(), but some encoding-aware function.) > this is even more true if you see there's a memcpy() function that is quite > the same as what strncpy() is. No it isn't. strncpy() stops when it encounters a zero char (byte). memcpy() always copies exactly the requested number of chars (bytes). > Then considering both strncpy() and > g_utf8_strncpy() takes the number of chars as the size argument That is a quite misleading misuse of the term "char". g_utf8_strncpy() takes the number of Unicode characters (code points), each of which is represented by one or more bytes. Not "chars". Please let's stick to using the term "char" to always mean what it means in C, i.e. "byte" or "octet" (as long as we ignore weird architectures). If you mean the more abstract concept "character", say so! --tml _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list