On Sat, Jan 18, 2025 at 01:23:07AM +0100, Alejandro Colomar wrote: > There's no other length. You could just call it len. pathname_ just > adds noise here. See the section on "Variable names" here: > <https://doc.cat-v.org/bell_labs/pikestyle>. OK. The variable is now named len in my local version of pathname(7). I’ll submit a new version of the patch once we wrap up the passing a null-terminated string to iconv(3) discussion. > I don't think we need a loop. Do you? iconv(3) should convert the > entire string if it is valid and there's enough room. You’re right. After rereading iconv(3), I’m now realizing that iconv() will only return if it finished converting the entire string, or it encounters an error. I’ve removed the loop locally. I’ll submit a new version of the patch once we wrap up the passing a null-terminated string to iconv(3) discussion. > > iconv_result = > > iconv(cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft); > > It seems you're passing a non-terminated string, and thus it's producing > a non-terminated string. Why don't you pass a null-terminated string? > > That is, inbytesleft should include be the length + 1. Here’re my concern: iconv(3) is going to see the final element of utf32_pathname and interpret it as a U+0000 null character. In some character encodings, U+0000 null is encoded as a single null byte. In other character encodings, U+0000 null is encoded as something other than a single null byte. For example, in Modified UTF-8, U+0000 null is encoded as the bytes C0 80. Is there any guarantee that nl_langinfo(CODESET) will return a character encoding where U+0000 is represented as a single null byte?
