Alejandro Colomar <[email protected]> writes: > Hi Sam, > >> Date: 2026-07-31 22:54:27+0100 >> From: Sam James <[email protected]> >> >> Alejandro Colomar <[email protected]> writes: >> >> > Hi Joseph, >> > >> >> Date: 2026-07-31 21:23:35+0000 >> >> From: Joseph Myers <[email protected]> >> >> >> >> I think it's irresponsible to use the man-pages project to promote >> >> personal idiosyncratic ideas like this in preference to what's been the >> >> standard location of functions since 1989. >> >> >> >> I'd rather we add a mandatory deprecation warning to memory.h in glibc. >> > >> > I hope you don't; it'd be a gratuitous breaking change. >> > >> >> Yet this change has the same effect, just people will see it themselves >> rather than the compiler telling them, and go around sending patches to >> change it. > > IME, people don't go changing includes unless they need something it's > not available in the already-included header files. > > Analysis of includes is quite complex, and there are tools for that > --iwyu(1)--. As long as those tools don't start complaining --and they > won't-- [1], I find it quite unlikely that people will start changing > includes in existing code. >
OK, that's useful behaviour. I wasn't aware it accepted a list of headers that would provide it. > This is rather something that will affect new code (new source files). > > [1] iwyu(1) works in a way that it allows a number of headers to > provide a symbol. If no header provides the symbol, then it > will recommend the best header for it; but if a header that > provides the symbol is already there, it won't complain. > >> The man pages should reflect what the standard currently says, not what >> you'd like it to say. > > Not exactly; the standard is a good guideline, but sometimes it's off. > We have vendor extensions, which are well documented, and when the > standard is bogus, the extensions take over the page. I think we have different views on the purpose of man-pages and users' expectations of them. > > FWIW, the information from the standard is still there. > > $ MANWIDTH=64 mansectf STANDARDS man3/memcpy.3 | cat > memcpy(3) Library Functions Manual memcpy(3) > > STANDARDS > C11, POSIX.1‐2008. > > ISO C and POSIX declare this function in <string.h>. > > Linux man‐pages (unreleased) (date) memcpy(3) > > I've just removed it from the front of the page (SYNOPSIS), but it's > still there, because of course, we must document the standard alongside > the extension. > >> We had the same problem with e.g. stripping "C89" >> everywhere. > > Sorry for that one; it was a useful change, though. Now we have better > manual pages than we had back then, regarding standards. I hope you > realize about that. It triggered discussion, and a careful review of > the text, which resulted in a good change after all. Yes, we got there in the end, but it was very disruptive, and caused a lot of pain. I am not sure the right lessons have been learned from it. > >> People want it to reflect what the standard says. > > And it still does. > > > Have a lovely night! > Alex
signature.asc
Description: PGP signature
