On 2024-10-18 at 04:51:55, Jeff King wrote: > 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. I think there's a tradeoff here in what is reasonable to support. For example, we know FreeBSD and NetBSD return something than the POSIX-mandated ELOOP for an open(2) on a symlink with O_NOFOLLOW. This is really minor to work around, and overall, both operating systems overwhelmingly are easy to support and run almost all POSIX-compatible software with ease and support a modern POSIX version. And then we have uclibc, which has decided to optionally fail to implement obligatory functionality that has been around for 35 years, which is longer than some of my colleagues have been alive. This isn't even that it doesn't implement all of the POSIX functionality, but that it doesn't even support what was standardized in C89—not C17, or C11, or C99, but C89. I should point out that the entirety of musl, a competing libc which does ship with fully functional wide character support, is less than 800 KiB in shared object form, so there's really no defensible reason for this option to even exist. Nobody is shipping even embedded Linux systems with so little storage or memory that this option matters (because you need a decent amount of space for the kernel as well), especially considering that flash can be cheaper than CAD 0.06 per GB. The difference is one set of systems has a minor incompatibility that requires little work to work around and has few practical effects, and the other tried to exclude major functionality from a tiny, ancient standard, the result of which is a wide variety of software that's broken. (For example, ncurses normally builds a wide character version of the shared library in addition to the byte-based version.) So I agree that we should allow minor variances for nonconformance, because very few systems practically comply with all of the standards (Linux, for example, does not). That's a prudent and sensible thing to do, and we should definitely continue to do that in the future. But given that this is major core functionality in the standard and there's actually an option to include it which this distributor has just chosen not to enable, I think it's fine for us to tell the distributor to just use the appropriate compile-time option for their libc. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
