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

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

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

Hi Oskari,

On 3/13/23 02:42, Oskari Pirhonen wrote:
[...]

> I'm neutral on removing POSIX.1-1996 if it was barely mentioned to begin
> with (a search on patch found just 2 instances of "1996") which is not
> the case for C89.
> 

[...]

>> <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, ...);
>>
> 
> I gave this a quick spin and it seems to work decently well. So thanks
> for that.

:-)

> It's still not quite as nice as having C89 mentioned in
> STANDARDS, and couldn't this be leveraged to fix up the inconsistencies
> you mentioned earlier?

Yup, you caught me.  That's what I thought when writing the email.  :p

> 
>>
>>>
>>> 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.
>>
> 
> I appreciate the honesty WRT admitting to editorializing. Even if we
> disagree on it here.
> 
> "Usefulness" seems to be a hard sell for you, but perhaps you would
> reconsider it based on the historical relevance of C89? It was, after
> all, the first proper standard of the C language. If you don't want to
> promote C89 by having it mentioned alongside the others, perhaps you'd
> be open to the idea of adding a historical note?

I've been considering something like that for a long time.  The
STANDARDS section (previously known as CONFORMING TO), is a mix of a
proper standards section, and what a HISTORY section should contain.

It would be interesting to do a split, and inaugurate a HISTORY section.
For that section, I would keep any references to C89, since as you say
it's historically very relevant.  Thus, I will revert the patch, and later apply some patches that move the info without discarding it.

Cheers,

Alex

> Saying that C89 is
> obsolete in the note would be acceptable IMO, but not having any mention
> of C89 at all makes the manpages feel incomplete. Others have shared
> this sentiment when chatting with them online.
> 
> There is also somewhat of a precedent of such a line being included in
> STANDARDS. For example, the following excerpts from gets(3) and
> printf(3), respectively:
> 
>> LSB deprecates gets().  POSIX.1-2008 marks gets() obsolescent.
>> ISO C11 removes the specification of gets() from the C language,
>> and since version 2.16, glibc header files don't expose the
>> function declaration if the _ISOC11_SOURCE feature test macro is
>> defined.
> 
>> The dprintf() and vdprintf() functions were originally GNU
>> extensions that were later standardized in POSIX.1-2008.
> 
> - Oskari

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]