Date: Tue, 4 May 2010 16:39:16 +0300 From: Jukka Ruohonen <jruoho...@iki.fi> Message-ID: <20100504133916.ga9...@marx.bitnet>
| In my manual page: [...] | What was the problem again? Something odd - sorry - it looks as if my (older) "nroff -mandoc" on current sources manages to lose the reference to that standard, though I have no idea why (the same macro works just fine for the earlier references in the paragraph, maybe my macros don't understand the arg). But I see the text you quoted in the source, so that's fine, sorry. | It may be very important to someone to know which functions conform to the | "stupid standard", possibly to limit something to some dialect only. I have no problem with that (but note I didn't say "stupid standard" anywhere...). Documenting what does conform is just fine, it is just what to do with functions that don't (and in this context particularly, functions which once did, but have been removed.) | As something like gets() has been standardized for ages, it makes sense to | explicitly note that this may no longer be true (with respect to POSIX). That's where I disagree, it is just bloat - once it stops being a standardised function, just stop calling it one. If the doc notes that fgets() is POSIX, and says nothing about gets(), the implication is quite clear, isn't it? | This way a reader (and whoever maintains the page) can also have some sense | of history, which is always important in itself. That history will be in the CVS logs. That's enough for maintainers. For others reading the man page, this is all irrelevant (it would almost be better if doc of gets() was deleted completely - the function has to remain, but there's no good reason to tell people they can use it if they're not already doing that.( | Unlike e.g. ISO, POSIX dares to deprecate stuff, which is a good thing, IMO. | In the future, if for instance a function f() is removed from glibc due | this, we might want to follow and move f() to some compatibility layer. I doubt glibc would ever remove anything that important, and I'm very confident that NetBSD never will - recommend against using it, sure - change all NetBSD code to avoid its use, definitely (that's probably already happened), but remove it (from libc, regardless of where else it might be added) - not a chance. That's not just gets(), it is everything (that's documented) which is in libc. kre