Re: clar unit testing framework FTBFS on uclibc systems (wchar_t unsupported)

[Patrick Steinhardt <ps@pks.im>]

On Fri, Oct 18, 2024 at 12:51:55AM -0400, Jeff King wrote:
> On Thu, Oct 17, 2024 at 10:21:43PM +0000, brian m. carlson wrote:
> 
> > > We unconditionally include <wchar.h>, and your system does not seem to
> > > have support for it built in. So why doesn't the `#error` trigger? It's
> > > also not like this is a recent error, it has been added with 581deed72
> > > (The obligatory forgotten files..., 2002-05-06).
> > > 
> > > We can do something like the below patch in clar, but I'd first like to
> > > understand why your platform seems to be broken in such a way.
> > 
> > Yeah, this is definitely broken.  We require ISO C99, and according to
> > the draft preceding the ratification[0], `wchar.h` and its contents are not
> > optional.  The similar draft for C11 also doesn't appear to make these
> > optional.
> > 
> > I think users of uclibc will need to compile it with full ISO C99
> > support.  I expect that a wide variety of other software will be
> > similarly broken without that.
> 
> Perhaps, but...don't the current releases of Git work just fine on such
> a wchar-less uclibc system now? We don't use wchar or include wchar.h
> ourselves, except on Windows or via compat/regex (though it is even
> conditional there). This is a new portability problem introduced by the
> clar test harness. And even there I doubt it is something we care about
> (it looks like it's for allowing "%ls" in assertions).
> 
> Our approach to portability has traditionally been a cost/benefit for
> individual features. Standards are a nice guideline, but the real world
> does not always follow them. Sometimes accommodating platforms that
> don't strictly follow the standard is cheap enough that it's worth
> doing.
> 
> I think more recent discussions have trended to looking at standards in
> a bit stronger way: giving minimum requirements and sticking to them.
> Certainly I'm sympathetic to that viewpoint, as it can reduce noise.
> 
> But IMHO this is a good example of where the flexibility of the first
> approach shines. We could accommodate this platform without any real
> cost (and indeed, we should be able to _drop_ some clar code).

Well, dropping doesn't work as it breaks other projects that depend on
the clar-features that depend on `wchar_t`. But other than that I agree
and would like to fix this issue, also because it potentially benefits
other users of the clar.

The only problem is that the platform seems to be severely broken. As
mentioned elsewhere, we have this snippet in uclibc's "wchar.h":

    #ifndef __UCLIBC_HAS_WCHAR__
    #error Attempted to include wchar.h when uClibc built without wide char support.
    #endif

So if __UCLIBC_HAS_WCHAR__ is not defined, we should see the error. But
the report didn't show the error, which means that the define has to be
set. And consequently we have no way to patch around this, because the
macro that we're supposed to use is broken.

Might be I'm missing something with how uclibc is intended to work. But
if I'm right then this is just a broken platform, and I don't think
working around it would be sensible. Otherwise I'd be happy to make the
wchar-related code conditional as shown in the preliminary patch posted
in [1].

Patrick

[1]: <ZxEXFI80i4Q_4NJT@pks.im>