Hi Branden, Doug, > Date: 2026-08-01 14:54:35-0500 > From: "G. Branden Robinson" > > Hi Doug, > > At 2026-08-01T08:39:08-0400, Douglas McIlroy wrote: > > Branden wrote > > > I'm sure I don't need to bring to your attention what a mine field > > > string/`char` sequence/memory buffer handling has been in C since > > > the language's inception. > > > > Yes, this is a property of the language, not a peculiar deficiency of > > the functions. Actually, I'm going to disagree on the first principle: the language is not flawed, and functions aren't particularly bad either. The fact that they can be used safely after you understand the tools means that the tools are good. It's the teaching that has been bad. Just like with every sharp tool, you need to first understand the tool. After 5 years of researching about functions, I've proved with example that one can rewrite vast amounts of string code without regressions every two lines of code. This can only mean that is not inherently dangerous, since I'm not especially free from the human-mistake factor (actually, I feel I'm more prone to them than the average programmer). lacks a few functions and macros that make life much simpler, such as Linux's strscpy(9), gnulib's streq(3), and a few others. That lack, I attribute it to the fact that programmers have been burnt so many times on bad design that they have grown an aversion to adding them. The fiasco of Annex K has probably helped. > I mostly agree. I think it's possible that C's string interfaces > managed to innovate some deficiencies of their own on top of those > proferred by the underlying the language definition. 8-O > > > As I see it, patching up perceived deficiencies of the functions adds > > complexity to the language definition and to the task of code-reading, I'm currently just proposing a documentation change (there's another proposal I'm working on in parallel, which actually affects the functions, but that's not what we're discussing now). The functions are virtually moved to a different header file, but nothing else changes. That header file division will help with the teaching problem, which is the problem that has affected so badly for so long. > That's true. But it is also true that without clear guidance from the > standard's specification of the library, and with the flagship text on > the language having gone unrevised since 1988, those perceived > deficiencies cause ad hoc innovations to sprout like mushrooms after a > thunderstorm. Some of those innovations, like OpenBSD's strlcat and > strlcpy (1998), claw their way into acceptance. And interestingly, OpenBSD's strlcpy/cat(3) suffer from DoS, which Linux's strscpy(9) is free of. > Others don't, and > remain bespoke features of a particular code project--often with little > commentary or accompanying documentation to illuminate them. Indeed. > The result? Reading _any_ code that involves string/`char` sequence/ > memory buffer handling has a substantial complexity tax stuck onto it. And indeed. > Culturally, it used to be that any inadequacies of the C language or its > standard library were hand-waved away because a coder of sufficient > ability could bull through any challenge with cleverness. Our community > has been purged of that preening vanity ten thousand CVEs at a time. And indeed. > I think one of the reasons Alex is getting pushback is that everybody > knows this is a horrible can of worms I'd say they think they know. I believe it's not a can of worms, if you are strict about keeping it simple. > --Joseph referred to "relitigation" And because the C Committee has the bad habit of considering past decisions of the committee as godspell, no matter how bad they prove to be. I've been repeatedly accused of relitigating realloc(p,0), , and many more bad decisions of ISO C. One good news is that Microsoft is currently testing my proposed changes to fix realloc(p,0), and when their testing is done, all the FUD that we've been hearing that it can't be changed now because "it would break the world" will just vanish. > --and that in turn is because seasoned C practitioners have a shared > dread that instead of a brilliant solution existing somewhere in library > design space, we face only struggles over who the taxing authorities > shall be. And everybody hates the tax man. > > > with little real benefit. > > If there is no Pareto improvement available in any dimension, but just > reshuffling of code-reading tax authorities, then you're right. > > I can, at best, hope the situation is not that bad. I am certain that the solution exists. > If it is, what is to be done? Have a lovely night! Alex --