Hi Stephane, On Mon, Jun 23, 2008 at 10:51 AM, Stephane Chazelas <[EMAIL PROTECTED]> wrote: > On Mon, Jun 23, 2008 at 10:34:14AM +0200, Michael Kerrisk wrote: > [...] >> Okay -- I verified this. >> >> One of the problems here of course is that the scanf.3 page currently >> doesn't document *any* errors... >> >> > and possibly to EINVAL for a >> > figures not in the requested base. >> >> Can you provide an example where this error is produced? I could not see it. > > Hi Michael, > > I didn't try that, that's why I said "possibly". But the > strtol man page says that it may return EINVAL so it could be > the case for sscanf as well.
Okay. Looks like it's not the case. > [...] >> > Also, the %as GNU extension seems not to be documented >> > (it may return ENOMEM) in the man page. It is in the glibc >> > documentation. >> >> So, this is a completely unrelated issue (other than the fact that it >> involves scanf()). Makes it difficult to close the bug and until the >> two unrelated halves are both fixed. Please don't do that ;-). > [...] > > You're right, sorry about that. Actually I found that other one > while writing the bug report. I was looking for other errnos > that sscanf may return (here ENOMEM). Yes, I included ENOMEM in the new ERRORS list. > But I'm not sure if that's a bug or not as I don't know whether > manpages-dev is meant to document the GNU or other version of > the libc functions. I don't know that manpages-dev has a policy on that. Upstream man-pages policy is: yes, document glibc specifics (but give context re portability). > AFAICT, the %as is a GNU extension that is > not supported anywhere else, but is required by the LSB. I don't > know what's your policy on that. As above. > I can create a separate bug report if you want. No, I'll fix the other part this time. Later today with a bit of luck. But please remember, next time(s). > BTW, Michael, I take it you're the maintainer of the > manpages-dev debian package, Sometimes one could get that impression ;-). But, no, I'm not. I'm merely the upstream maintainer. (Debain derives the downstream manpages and manpages-dev packages from my upstream man-pages. The Debian maintainer is Joey.) Debian makes it easy to track their downstream man-pages bug reports, so I do that. It's useful for me to get bug reports that way, because Debian users are quite active in reporting documentation bugs. It's useful for Debian, because I shorten the average response time on documentation bug reports considerably (and mostly save Joey the job of pushing fixes upstream). > but are you as well the maintainer > of the upstreams package, or glibc documentation? Just upstream man-pages, which does document glibc in Section 3. I have nothing to do with info docs though -- that's the glibc folk. > What's the debian view on the LSB. I don't know. > I discovered it recently. It > seems more like an industry initiative to me at first sight > rather than a free software initiative and it seems to be > somewhat RedHat centered so am not sure what kind of credibility > it can be given. I don't think you could call it RH centric. Thre are many parties involved. Perhaps RH is more active than many. Mats might have something to say about this. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
