Re: g_malloc overhead

[Tor Lillqvist <tml iki fi>]

> 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