Re: CVS commit: src/lib/libc/stdio
On Wed, May 05, 2010 at 08:05:20AM +0200, Alan Barrett wrote: On Wed, 05 May 2010, Jukka Ruohonen wrote: Few examples of pages that are badly and *systematically* behind: intro(3) intro(4) pci(4) usb(4) mk.conf(5) sysctl(7) Perhaps we need a bot to watch all commits and send reminders like You added a new file, but you haven't updated the sets, see URL for instructions, You added a new sysctl node but you haven't updated sysctl(7), etc. For this kind of stuff it should be easy enough to write some shell scripts that check consistency. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/share/man/man9
On Tue, May 04, 2010 at 05:16:58AM -0700, Paul Goyette wrote: +The functions were originally introduced to handle +.Tn PCI +bus master devices, which assumed little endian byte order in +.Tn DMA +transfers, even on big endian systems. There are a few PCI bus master devices that are big endian aware (epic(4) for example), so I don't think it's appropriate to add commas around the which clause. I agree that the first comma should go, but the second one (before even) should remain. No it shouldn't. Anyway, I just rearranged it to hopefully avoid such problems entirely. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? That it does not set the errno? Well, I am not the one who deals with libc, but personally I think strict conformance is not needed in a small detail like this, as long as it is documented behavior. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 12:04:53PM +0300, Jukka Ruohonen wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? That it does not set the errno? Well, I am not the one who deals with libc, but personally I think strict conformance is not needed in a small detail like this, as long as it is documented behavior. Actually, it is even optional. I fixed that. - Jukka.
Re: CVS commit: src/share/man/man9
+The functions were originally introduced to handle +.Tn PCI +bus master devices, which assumed little endian byte order in +.Tn DMA +transfers, even on big endian systems. There are a few PCI bus master devices that are big endian aware (epic(4) for example), so I don't think it's appropriate to add commas around the which clause. I agree that the first comma should go, but the second one (before even) should remain. No it shouldn't. Anyway, I just rearranged it to hopefully avoid such problems entirely. cvs rdiff -u -r1.6 -r1.7 src/share/man/man9/byteorder.9 -bus master devices which assumed little endian byte order in +bus master devices that do little endian .Tn DMA -transfers, even on big endian systems. +transfers on big endian systems. What's little endian transfer? IMO, DMA transfers are always stream (no byte reordering) and hto*()/*toh() functions are used to encode/decode values larger than a byte into/from the stream before/after transfers per byte order the target bus master device assumes. That was what a dumb sentence in rev 1.1 meant. --- Izumi Tsutsui
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 07:48:59AM +, David Holland wrote: On Wed, May 05, 2010 at 08:05:20AM +0200, Alan Barrett wrote: Perhaps we need a bot to watch all commits and send reminders like You added a new file, but you haven't updated the sets, see URL for instructions, You added a new sysctl node but you haven't updated sysctl(7), etc. For this kind of stuff it should be easy enough to write some shell scripts that check consistency. A simple look should reveal the inconsistency. So the first approach sounds more fruitful. But to me, the problem is that we need a good amount of manual labour to keep those updated. Isn't this the kind of task where computers, not humans, are good at? As we've talked about history, it is worth to remember that those lists came from some early BSD where things were small and simple. Though, once those have been undocumented or unmaintained for couple of years, it takes some detective work to figure out what all those knobs and switches are, and even then it may not be entirely clear. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. Joerg
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 02:48:32PM +0200, Joerg Sonnenberger wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. RETURN VALUE Upon successful completion, fileno() shall return the integer value of the file descriptor associated with stream. Otherwise, the value -1 shall be returned and errno set to indicate the error. ERRORS The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 06:00:45PM +0300, Jukka Ruohonen wrote: On Thu, May 06, 2010 at 02:48:32PM +0200, Joerg Sonnenberger wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. RETURN VALUE Upon successful completion, fileno() shall return the integer value of the file descriptor associated with stream. Otherwise, the value -1 shall be returned and errno set to indicate the error. ERRORS The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? I don't mind if it sets errno, but I am not sure if POSIX makes a lot of sense here. But that's just me. Joerg
Re: CVS commit: src/lib/libc/stdio
On 6 May 2010, at 9:14, Jukka Ruohonen wrote: Module Name: src Committed By: jruoho Date: Thu May 6 08:14:08 UTC 2010 Modified Files: src/lib/libc/stdio: ferror.3 Log Message: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. Is there any reason not to make in compliant? It seems like a reasonable change. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/lib/libc/stdio
In article 20100506150045.ga...@marx.bitnet, Jukka Ruohonen jruoho...@iki.fi wrote: On Thu, May 06, 2010 at 02:48:32PM +0200, Joerg Sonnenberger wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. RETURN VALUE Upon successful completion, fileno() shall return the integer value of the file descriptor associated with stream. Otherwise, the value -1 shall be returned and errno set to indicate the error. ERRORS The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? Our stdio supports funopen() which has FILE *'s where fileno() == -1, but they work just fine... This should be documented. Perhaps set errno if it is indeed a bad file descriptor, and don't set it if it is a side-effect of funopen()? christos
