Hi, On Fri, Mar 10, 2023 at 14:29:24 +0100, Alejandro Colomar wrote: ... snip ... > >> The main problem was that the existing info about C89 was not consistent. > >> Some pages declared APIs being standard since C89, while others didn't. > >> Incorrect info isn't much better than no info. > >> > > > > This is something that can (and should) be fixed then, instead of > > blindly dropping all references to C89, no? > > We decided back in 2020 that it wasn't worth the extra effort to > check C89. ... snip ... > But there are many standard. Who decides which to mention and which > not to mention? How about POSIX.1‐1988, POSIX.1‐1990, and > POSIX.1‐1996? > > There are still projects out there that care about POSIX.1‐1996, and > that's not compelling enough for me to do the extra work of searching > if something happens to be supported by it. I will just state > POSIX.1-2001, which is the oldest one I care about, and live with it. > > In fact, some pages documented POSIX.1‐1996, and I removed any mentions > to it in the same commit that removed mentions to C89, and even forgot > to mention it in the commit message. > I'm neutral on removing POSIX.1-1996 if it was barely mentioned to begin with (a search on patch found just 2 instances of "1996") which is not the case for C89. > > >> I'd like to really understand the need for C89 in 2023. > >> > > > > Some projects might like C89 and there's not much that can be done on > > that front without the maintainers having a change of heart... > > If you really want C89, I suggest (as I did in the commit message) that > you read the C89 Standard itself, which will be much more precise than > the Linux man-pages have ever been or will ever be. > > However, I suggest you change your heart, and consider C99, since that's > the future (or the past, I should say). I would at least ask that you > show _proof_ that you _need_ C89, before I consider spending some extra > time in documenting C89 in the man pages. > I think you misunderstood what I meant here. I've got nothing against using current versions of the language. Perhaps that was not clear enough in my message. > Especially, when you can just download a plain text version of the C89 > Standard, and grep(1) for the function name you're interested in: > > <https://port70.net/~nsz/c/c89/c89-draft.txt> > > I suggest you download that file, and use a function like this: > > $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; } > $ stdc89 printf > int printf(const char *format, ...); > int printf(const char *format, ...); > I gave this a quick spin and it seems to work decently well. So thanks for that. It's still not quite as nice as having C89 mentioned in STANDARDS, and couldn't this be leveraged to fix up the inconsistencies you mentioned earlier? > > > > > Personally, I see this more as an issue of manpages inappropriately > > editorializing. Mentioning in DESCRIPTION of gets(3) to "Never use this > > function" is perfectly fine. In fact, I applaud that it's emphasized > > before even getting into what the function does. > > > > From the original commit message: > > > >> Let's move forward, so readers get the intended notice that C89 is not a > >> useful version of C. > > > > This is incorrect. I can write useful code, even in C89. > > > > More importantly, I find it to be an inappropriate attitude for a manual > > to take. > > I admit some editorializing. I think there needs to be some. Otherwise, > there will always be some projects that request support for their > favorite standard. We're close to the point where C89 becomes irrelevant. > I admit we're not yet there, but I'm not sure if it's because it's really > needed, or because some projects blindly stuck to it for fear of the > unknown. I believe it's the latter, and would like to ask you to try C99, > or show some proof that you still need C89 for some reasons that are > different from "I like it". Please understand that I'm not going to > spend my time on documenting POSIX.1-1988 or even K&R C just because > some project likes it (there are still projects that use K&R functions). > > However, if you show me that some system can't possibly have C99 in any > form, because there's no C99-compatible compiler or libc that runs on > that system, I would reconsider reverting the patch. > I appreciate the honesty WRT admitting to editorializing. Even if we disagree on it here. "Usefulness" seems to be a hard sell for you, but perhaps you would reconsider it based on the historical relevance of C89? It was, after all, the first proper standard of the C language. If you don't want to promote C89 by having it mentioned alongside the others, perhaps you'd be open to the idea of adding a historical note? Saying that C89 is obsolete in the note would be acceptable IMO, but not having any mention of C89 at all makes the manpages feel incomplete. Others have shared this sentiment when chatting with them online. There is also somewhat of a precedent of such a line being included in STANDARDS. For example, the following excerpts from gets(3) and printf(3), respectively: > LSB deprecates gets(). POSIX.1-2008 marks gets() obsolescent. > ISO C11 removes the specification of gets() from the C language, > and since version 2.16, glibc header files don't expose the > function declaration if the _ISOC11_SOURCE feature test macro is > defined. > The dprintf() and vdprintf() functions were originally GNU > extensions that were later standardized in POSIX.1-2008. - Oskari
Attachment:
signature.asc
Description: PGP signature
