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:

quoted

quoted

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]: [ref]