Alejandro Colomar writes: > Hi Sam, > >> Date: 2026-07-31 22:59:47+0100 >> From: Sam James >> >> (*) Alex has a history of making opinonated changes like this to >> man-pages, such as removing references to older standards, and using a >> somewhat novel (to many) syntax for prototypes. > > I think this comment deserves a well thought response. > > "Opinionated" is your subjective knee-jerk way of saying it. I don't > agree with it. I don't consider it kneejerk. It's an opinion I've formed over the years. You're of course free to disagre with it. > > I'd say I have a history of making changes based on thorough revision of > history and technical merits, even when that research is contrary to > decades (or half-centuries) of common practice, and possibly to > current or withdrawn standards. The primary issue I have is that I don't often see you change your mind or acknowledge that being the man-pages maintainer is a privileged position, or separate your desires from the maintainership role. When I'm acting in a maintainer role, I often take changes I don't particularly agree with if they're technically sound and there's broad consensus for them. I think many do. > > In this case, and I don't mean this specific patch set, but the years- > long revision of string documentation that I've been carrying out, we > have a conflict between the design and correct use of string and memory > functions, and their common use today. > Yes, I don't dispute that the terminology is poor. > The functions that are most subject to this conflict are strncpy(3), > strncat(3), and memccpy(3). But the rest of strn*() are also somewhat > affected, and the rest of mem*() minorly affected. > > They were originally designed for a specific use case for which they > were great. This knowledge has been lost in time, and I've been working > to recover that knowledge. > > Precisely because of standards and other documentation that isn't > written with the level of care that I have, we have decades of misuses > of strncpy(3) and strncat(3). > > Moreover, it's in other places that you should be complaining about. I do complain about those, and we finally got some consensus on the GCC side on not warning about a bunch of them by default, even. > GCC has a bogus set of diagnostics about strncpy(3) and strncat(3), > which we could very well call opinionated, and I haven't seen anyone > reporting them as bogus before I did. Those diagnostics have not been > considered opinionated, just because they follow mainstream (bogus) > usage of these functions, but they are indeed forcing an opinion of how > these functions should be used over other uses that may be more uncommon > but which are actually the original and correct uses of these functions. > > > > > It's curious that you called the GCC diagnostic "heuristics" instead of > "opinionated". There's nothing about heuristics there. It's just an > enforcement of an (incorrect) opinion about how these functions should > be used. The warnings are both opinionated and heuristics-based. I'm not sure how you could read the comment you linked to as somehow an endorsement of the status quo, I've been quite vocal about changing it elsewhere too? > > And since C23, we're seeing that the same story is repeating with > memccpy(3), which was once a niche function that was great for > implementing fgets(3), and now is misused by everyone and their dog for > copying strings with truncation. > > I have spent probably more time than anyone in the last 5 years > researching about string handling, and have proven the correctness of my > research in the shadow-utils project, where most of my work has been in > revising string and memory handling code. I've fixed uncountable subtle > bugs in such code, and have made the resulting code actually readable. > And the number of accidental regressions is minimal (IIRC, one or two > regressions related to string and memory handling, in all that time, and > not too dangerous). > > Thus, I think it is my responsibility, as maintainer of the > documentation project most read by C programmers, to let our audience > learn what I've learnt in these years, and allow them to write safe > string- and memory-handling code. > > It is thanks to this years-long research that I've been able to gather > important knowledge from people like Mark Harris, Doug McIlroy, Branden, > and many others, who hold knowledge that few other programmers possess, > and spread it to the world. > > I'd consider it a negligence to do the easy thing and follow what > standards say, or what most programmers do, because that's what has led > us to the well-known mistakes that C programmers make. > > FWIW, regarding the possible conflict of interest that was mentioned > yesterday, I'll say that I don't get paid for my contributions to ISO C > as a member of WG14. There's no benefit to me other than public > recognition. I'll also disclose the exact quantity that I've been paid > for maintaining the Linux man-pages project: You can have a conflict of interest in responsibliity without money being involved. In fact, I have never believed you were influenced by money, just that you let your personal opinions unduly influence your decisions in modifying man-pages, even when consensus seems against it. > > 110 kUSD in 2025 (from 5 sponsors) > 75 kUSD in 2026 (from 3 sponsors) > > I'm convinced that that doesn't have any effects in my decisions here, > as I've had a consistent record of decisions well before I had any > economic benefits from maintaining this project. None of those sponsors > have expressed any interest in favour of these decisions (nor against). > > I'll rumiate a bit more on these patches, and probably make minor > changes to them, but the essence of documenting for all of > mem*() and strn*() in SYNOPSIS is most likely to be eventually merged. > I'll be careful to document what the standards say in a way that isn't > confusing to users, and also in general will try to document it in a way > that is positive for our audience --even if some of that audience may > have knee-jerk reactions, like you are having at the moment--. I have > also received very positive feedback for other changes for which some > people have noisily had knee-jerk reactions. I believe it is my duty > as maintainer of this project to do this change. > Please stop saying I'm having a kneejerk reaction. I haven't even yet commented on the substance of the changes, I've just commented on how I don't believe in making changes through man-pages like this. > > Have a lovely day! > Alex sam