Hi Sam On 3/23/23 06:32, Sam James wrote: > > Alejandro Colomar <alx.manpages@xxxxxxxxx> writes: > >> [[PGP Signed Part:Undecided]] >> Hi Matt, >> >> On 3/10/23 02:51, Matt Jolly wrote: >>> Hi All >>> >>> I hope this email finds you well. I am writing to raise an issue that has been causing inconvenience >>> for me (and potentially others). The recent removal of C89 information from man pages >>> (72b349dd8c209d7375d4d4f76e2315943d654ee9) has put me in a difficult situation. >>> As I continue to work on code that adheres to the C89 style, such as cURL, I am unable to quickly >>> determine if a particular function can be used or if it was introduced in a later standard like C99. >>> This slows down my workflow and hampers my productivity. >>> >>> Therefore, I kindly request that we revert the changes made in the "Many pages: Remove references to C89" patch. >>> Furthermore, I urge everyone to recognize the importance of this information and ensure it is not removed from man pages in the future. >> >> 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. >> >> I'm curious about cURL's real need for C89. I see that cURL uses GNU >> extensions (-std=gnu89), which actually pulls most of C99[1] (I think >> it pulls the entire C library, and most of the core language). > > I don't really agree with it, but the gist is at > https://daniel.haxx.se/blog/2022/11/17/considering-c99-for-curl/. > > The general principle here being two things, I guess: > 1. It's pretty useful to have this information (even if it's just > on a best-effort basis) because I can cite it in arguments even if > a project is using >= C99. > > 2. People expect the information to be there, so omitting it ends up > giving the impression something just isn't in C89, rather than the > reader realising the information is removed from the man pages entirely. > > but also, and this was the case for Matt here: > > 3. I don't always have a choice. Especially doing distribution work, > I end up patching and contributing to all sorts of projects, and while > I wish many things would use newer C, they're either dead projects, or > their maintainers are of a strong mind on the matter. > >> >> Virtually all (even MS, which has always been the last in this) >> systems support C99; why would you consciously avoid it? Is there >> any system that doesn't yet support it? Which are the C libraries >> that you need to support that don't provide C99 functions by default >> (or at all)? >> >> I'd like to really understand the need for C89 in 2023. > > i.e. what I'm saying is that it's not so much about the need, but rather > that changing the man pages just ends up inconveniencing people who > aren't really happy about using C89 either. Makes sense. And yeah, history is always useful, even for corner cases, which is why we still document things like 4.0BSD. I'm almost finished in adding the HISTORY section and reorganizing VERSIONS and STANDARDS (and NOTES). This week or next week, I'll push the commit. So far, I've done: 536 files changed, 4704 insertions(+), 4278 deletions(-) And there are still 353 pages pending. :) But the change is looking quite good. I think it will be a nice improvement. Cheers, Alex > > best, > sam -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
