On 3/10/23 14:29, Alejandro Colomar wrote: > Hi Oskari, > > [reordered your sentences for my reply] > > On 3/10/23 06:00, Oskari Pirhonen wrote: >> Hi, >> >> On Fri, Mar 10, 2023 at 03:22:12 +0100, Alejandro Colomar wrote: > > [...] > >>> 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. I forgot to add a link here. <https://lore.kernel.org/linux-man/23bfb4c9-9cab-8d1f-46a2-00932501b5b8@xxxxxxxxx/> > > [...] > >>> 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... >> >> What is not fine, on >> the other hand, is saying that it's in C99 and POSIX.1-2001 but giving >> the impression that it's all of a sudden _not_ in C89 anymore. >> >> The STANDARDS section should not be the place for opinions, >> rather facts about when something was standardized. If this is not the >> case then perhaps it should be renamed to something else. "STANDARDS >> EXCEPT ONES WE DON'T LIKE" comes to mind. >> > > 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'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. > > 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, ...); > > >> >> 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. > > Cheers, > > Alex > >> >> - Oskari > -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
