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:
OpenPGP_signature
Description: OpenPGP digital signature
