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. [...] > > 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). 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. 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. I can create a separate bug report if you want. BTW, Michael, I take it you're the maintainer of the manpages-dev debian package, but are you as well the maintainer of the upstreams package, or glibc documentation? What's the debian view on the LSB. 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. Cheers, Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
