On 2023-07-11 11:39, Bruno Haible wrote:
Paul Eggert wrote:
Even if
mbsinit returns nonzero, things are still OK if further scanning behaves
as if the mbstate_t were all zero. Although this implementation behavior
would be silly, POSIX doesn't prohibit it
we don't need to bother about this situation.
I agree. It's merely a theoretical POSIX-conforming platform, and Gnulib
needs to be portable only to practical platforms.
+# if GNULIB_MBRTOC32_REGULAR
+ /* Verify that mbrtoc32 is regular. */
+ if (ret < (size_t) -3 && ! mbsinit (ps))
+ /* This occurs on glibc 2.36. */
+ memset (ps, '\0', sizeof (mbstate_t));
+ if (ret == (size_t) -3)
+ abort ();
+# endif
Since this is inside mbrtoc32, performance is relevant, so shouldn't
this be tested at configure-time instead of at run-time? That is,
shouldn't the "#if" test be something more like "#if
GNULIB_MBRTOC32_REGULAR && HAVE_MBRTOC32_RETURNS_MINUS_3", where
GNULIB_MBRTOC32_RETURNS_MINUS_3 is zero on all known platforms?
Well, since I reported https://sourceware.org/bugzilla/show_bug.cgi?id=30611 ,
I expect to see a change in glibc behaviour in this area. But binaries
compiled with a current glibc should continue to work fine with future
glibc versions. This means, we cannot optimize through a configure test here.
I don't see why we can't optimize. Although Gnulib should be portable to
plausible future changes to glibc, it's implausible that glibc will
return (mbchar_t) -3 for that minor glitch in a rarely used legacy encoding.
More generally, we don't need to defend against hypothetical bad (but
POSIX-compliant) behavior being introduced into a future version of
glibc. For example, we needn't defend against glibc growing sizeof
(mbstate_t) to 10000 so that mbiter users should worry about stack overflow.
