Re: Revert "Many Pages: Remove references to C89"

[Oskari Pirhonen <xxc3ncoredxx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]

Hi,

On Fri, Mar 10, 2023 at 03:22:12 +0100, Alejandro Colomar wrote:
> 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.
> 

This is something that can (and should) be fixed then, instead of
blindly dropping all references to C89, no?

> 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).
> 
> 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.
> 

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

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

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

- Oskari

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]