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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

best,
sam

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux