Re: new module mbrtoc32-regular

[Paul Eggert]

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.