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'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
