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

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4997 bytes --]



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@gmail.com/>

> 
> [...]
> 
>>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]