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.
