Paul Eggert wrote: > > DEFINITION: We call an mbrtoc32 function_regular_ if > > - It never returns (size_t)-3. > > - When it returns < (size_t)-2, the mbstate_t is in the initial state. > > "the initial state" -> "an initial state". But even with that change > isn't the second part of this definition a bit too strict? 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
Not only this implementation behavior would be "silly". No known implementation behaves like this: In the extensive tests/test-mbrtoc32.c tests we have ASSERT (mbsinit (&state)); after every mbrtoc32 return < (size_t)-2, and none of these assertions fail on the various platforms. Likewise with mbrtowc and tests/test-mbrtowc.c. Therefore, we don't need to bother about this situation. And if it ever occurs, the unit test will tell us. > > +# 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. We could at most use a cached runtime test, but that is ugly code... Bruno
