bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: From wchar_t to char32_t, new module mbszero


From: Paul Eggert
Subject: Re: From wchar_t to char32_t, new module mbszero
Date: Tue, 18 Jul 2023 20:29:22 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 2023-07-17 09:53, Bruno Haible wrote:

On NetBSD, I apparently did not locate the right source code of the mbsinit
function, due to the complexity of the citrus code. And did not want to debug
it, because debugging in libc code without debugging information is often
a waste of time.

I looked into it. I think it's due to the funky business with struct _RuneStatePriv. There's a pointer's worth of data before the data that the converters see, and until recently there was another character that ended up perhaps needing another pointer's worth of padding. Two pointers (8 bytes each), plus the 12 bytes we already saw, would explain the 28 bytes you observed.

I fixed mbcel.h for that by installing the attached patch into diffutils. Thanks for pointing it out.


This macro is not used anywhere. How about adding a comment explaining
why it's defined but not used? Or if it's not needed we can remove it.

It's needed, namely as lower bound for _GL_MBSTATE_ZERO_SIZE:
0 < _GL_MBSTATE_INIT_SIZE <= _GL_MBSTATE_ZERO_SIZE <= sizeof (mbstate_t).

That's merely documentation, right? That is, only comments use the lower bound.

And I won't write
   sizeof (((mbstate_t) {0}).__count)
outside of comments, since the less identifiers with double-underscore
we use, the better.

On the other hand, the sizeof is more likely to notify builders if glibc changes internals in an incompatible way. (No big deal either way of course.)

One thing I noticed on NetBSD 9.3 x86-64 (it has GCC 7), is that it didn't optimize memset calls away. So in memcel.h I stuck with initializing by hand rather than using memset.

Attachment: 0001-diff-fix-mbcel-bug-on-NetBSD.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]