Re: CVS commit: src/lib/libc/stdio

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 4 May 2010 16:39:16 +0300
    From:        Jukka Ruohonen <jruohonen%iki.fi@localhost>
    Message-ID:  <20100504133916.GA9362%marx.bitnet@localhost>

  | 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