Re: [RFC] Some sr.ht CI tweaking

On Fri, Feb 13, 2026 at 10:57:19AM +0800, Kevin J. McCarthy wrote:
> On Thu, Feb 12, 2026 at 04:02:11PM +0100, Daniel Tameling wrote:
> > On Thu, Feb 12, 2026 at 01:20:18PM +0800, Kevin J. McCarthy wrote:
> > > 
> > > The ones in wchar.h include wcrtomb(), mbrtowc(), and wcwidth().
> > > 
> > > So, in this case, why are we only getting in trouble with wcwidth(), but
> > > not the first two?
> > > 
> > 
> > FreeBSD defines wcwidth as __wcwidth [1] and has in a different header
> > the complete implementation of __wcwidth so that it can always be
> > inlined [2]. An undef wcwidth solves the problem.
> 
> Thank you Daniel!  Rene, let's try adding a undef inside mbyte.h and see if
> that solves the compile problem you saw:
> 
>  #ifdef iswupper
>  # undef iswupper
>  #endif
> +#ifdef wcwidth
> +# undef wcwidth
> +#endif
>  size_t wcrtomb (char *s, wchar_t wc, mbstate_t *ps);
>  size_t mbrtowc (wchar_t *pwc, const char *s, size_t n, mbstate_t *ps);
>  int iswprint (wint_t wc);
> 
> > Honestly, wchar.h and wctype.h are nowadays part of POSIX and the C
> > standard, and have been for a long time. The workaround isn't really
> > needed anymore. If somebody disagrees, they should step up and maintain
> > the code. Your limited time is better spend elsewhere.
> 
> That would nice.  I wonder if we could mark --without-wc-funcs as deprecated
> in the 2.4.0 release and rip this stuff out in the 2.5.0 release?  I hear
> Steffen's objection, but isn't it reasonable to expect a system to have the
> wc functions by now?
> 
> If there is general agreement, then, Rene, perhaps we shouldn't invest too
> much time on CI testing the --without-wc-funcs on sr.ht.

AFAIU those functions are all either part of C99 or POSIX.1(2001/2008).
That's something between 27 and 18 years ago. I think it's OK to assume
everyone has them now.