Hi Branden, On Fri, Sep 19, 2025 at 10:37:13PM -0500, G. Branden Robinson wrote: > At 2025-09-19T09:48:29+0200, Alejandro Colomar wrote: > > I'm amazed how libc implementations have not added these things in > > such a long time. ANSI C brought good and bad things, and this > > freezing was one of the bad ones. > > They had some help from Dennis Ritchie. From what I've read, he was a > force favoring total inertia after C89, and pointedly had very little > comment once C99 came out, sitting out a third edition of his book with > Kernighan. > > Maybe his reasons were good ones, but I'd have to see them to judge. > I personally like virtually everything that C99 brought to the table.
C99 was good IMO too. C11 started adding crap. Think of Annex K, which still has strong support from the committee (I mentioned the possibility of removing it, and clearly we're not going to do that). C17 was a bug. I really mean that; one of the changes in C17 was breaking realloc(p,0). And then C23 had things that are great, things that could have been great but they rushed them and that went wrong, and things that look like great but they are really useless. In C2y, they obliterated the original charter, and they are now adding the craziest stuff ever. There's relatively decent support to deprecate <string.h> from part of the committee. And array parameters. And arrays. And pointers... > > I'm also amazed how a large amount of programmers will continue using > > strcmp(3) raw instead of adding their own trivial wrappers. > > I can tell you why I do it--accessibility and familiarity to newcomers > or drive-by contributors. Same reason you want me to get rid of > `array_length()` in favor of `countof()`. Still, I think that array_length() is better than using raw sizeof divisions. Everybody seeing a project using arrray_length() understands what you're doing; probably even more than using a raw sizeof division. countof > array_length > sizeof division streq > my_string_eq > strcmp IMO. > I admit, though, that groff doesn't get many drive-by contributors. > > > Code doesn't become less portable by defining useful macros and > > functions. > > No, but it can become less familiar and less immediately apprehensible > by already seasoned C/C++ programmers. I somewhat disagree with this. If you'd call it strings_equal() or whatever, that would still be readable to some degree, especially to seasoned C/C++ programmers. > > Agree. And that goes both ways. I think there's people that should > > be there and isn't. More specifically, I think there should be > > representation of the civilized world (glibc, musl, FreeBSD, NetBSD, > > OpenBSD, and POSIX). > > The Austin Group (POSIX, more or less) liaises with WG14 already. You > can find evidence of this in their teleconference minutes. That usually goes one way. The Austin Group listens to WG14, but WG14 doesn't listen to the Austin Group. > As for the others, have you tried reaching out to principals of these > libcs and asking them to participate? Are you *sure* they aren't > already? I think Joseph Myers is both a GCC committer and a WG14 > member. Joseph participates representing GCC. But there's no-one from glibc nor musl nor the BSDs. In fact, I needed glibc to participate in the last meeting to fix realloc(p,0), but they didn't show up. There are glibc members that are registered as members, but have never showed up since I've been in the committee at least. > I grant there's a distinction in emphasis between compiler vendors and > standard library vendors. But TTBOMK it's not the case that members of > the Free Software C ecosystem are wholly unrepresented. There's Joseph from GCC, Aaron from Clang, and I from the man-pages. When voting, 3 votes compared to 20 people don't do much. And the committee pretty much works like a bad democracy, where minorities are usually ignored. > > I understand you can't ask much of volunteers, but I think at least > > one maintainer of each of those projects should participate in the > > committee. I think what they're doing now, which is not innovating > > due to fears of collision with the committee, and taking blindly > > almost everything that the committee produces, is harmful to the > > language. > > If I'm not mistaken above, ask Joseph for his take. He's quite silent about his take. I've tried to extract it from him, but couldn't. > > Either they should be in the committee, or if they truly believe the > > committee has lost its mind, they should sit together in a table, and > > fork C into POSIX C, ignoring anything produced by the WG14. > > A split like W3C and WHATWG would be costly. One shouldn't ever rule it > out, but before seriously pursuing it (publicly) you want a lengthy list > of concrete and specific grievances first, one where the standards body > has demonstrably and documentably refused to act, or an executive panel > of some sort has overridden consensus. The U.S. Declaration of > Independence is this sort of document. :) Does removing the charter and replacing it by something else count? :) I would take the charter as the constitution, so they essentially changed their constitution (not that they had followed it much, but at least to some degree until now). > I followed the C23 ratification process fairly closely (observing the > giant spreadsheets they used to track feedback from the ISO balloting > process). The impression I formed was that the national standards > bodies (NBs) were much stronger forces resisting change than vendors > were, and particularly so with respect to the cutting of dead weight > (like trigraphs). NB comments are mostly ignored by the committee. Did you read the responses to NB comments? I saw some of them, and they are along the lines of "the comment goes against the consensus of the committee, we don't see reasons to change our decision". > Of course, that doesn't mean that vendors weren't pulling the strings of > the NBs. Remember OpenOffice XML? I did raise an NB comment to try to cancel nullptr(_t). I got the response shown above. But I wasn't the only one. And the comment was well motivated. Have a lovely day! Alex -- <https://www.alejandro-colomar.es> Use port 80 (that is, <...:80/>).
signature.asc
Description: PGP signature
