Sender: richdawe AT bigfoot DOT com Message-ID: <3A4B8307.F4EF8D0@bigfoot.com> Date: Thu, 28 Dec 2000 18:14:31 +0000 From: Richard Dawe X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.17 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: Eli Zaretskii CC: DJGPP workers Subject: Re: An implementation of /dev/zero for DJGPP References: <3A489766 DOT 349B3C71 AT bigfoot DOT com> <9003-Tue26Dec2000184539+0200-eliz AT is DOT elta DOT co DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Eli Zaretskii wrote: > > Richard Dawe wrote: > > > > Eli Zaretskii wrote: > > > If whatever link, fcntl, and ioctl will do with the null device is > > > appropriate for /dev/zero, you can simply leave these functions > > > unhandled. [snip] > Well, you could write a short test program to see what GNU/Linux > does. We could also say we don't care ;-) The link(2) man page on Linux lists the following error: "EPERM The filesystem containing oldpath and newpath does not support the creation of hard links." I think this is a valid error. Our /dev/zero resides in a virtual file system, so this seems appropriate. The following fcntl() "get" routines seem to be supported: F_GETFD, F_GETFL. I haven't tried the sets yet, but I presume they are supported. F_DUPFD is supported. F_GETOWN isn't. The FIONREAD, FIOGETOWN ioctls aren't supported, returning ENOTTY. FIONBIO is supported. I will update the /dev/zero FSEXT appropriately. > > If there are any good uses for /dev/full, then I'll add this. DJ's suggestion [in another mail] is good, so I'll add it. > But my point was more general than the current limitations: I don't > think that the fact that the handle doesn't have any data is a reason > to fail the call. OK, rather than fail, the FSEXT will not do anything - it will be passed through. > > Does the debug FSEXT work like this? Or does it leave the fd's data > > pointer alone? [snip] > Btw, since the debug support hooks the handle at startup (its > initialization routine is declared "__attribute__((constructor))"), it > is actually the /dev/zero FSEXT which will cause trouble, unless you > add special code to chain to the previous hook. Would the /dev/zero hook actually get called, when the debug FSEXT is present? Surely the debug FSEXT is the first FSEXT, because of the constructor. So, if a program using the debug FSEXT tries to open e.g. /dev/zero, it will fail, because the debug FSEXT "knows" nothing about /dev/zero. I think I am missing something here - the debug FSEXT is only used within the debugger, right? Its purpose seems to be to clean up any handles the child program has created. So the only problem I can see here is that the child program may not tidy up properly. The debug FSEXT will clean up its [file] handles. So, I think the /dev/zero cannot cause trouble with the debug FSEXT. (This is with /dev/zero being installed using __install_dev_zero(), as discussed previously.) > > Hmmm, I'm not sure we should allow overflow. I seem to recall that > > some programs I've seen test for failure by checking that the return > > value is less than zero. > > Those programs are buggy. > > > read() does not have to return the number of bytes asked for. > > It doesn't? I've seen gobs of programs which depend on the fact it > does. Unix98 says: "The value returned may be less than nbyte if the number of bytes left in the file is less than nbyte, if the read() request was interrupted by a signal, or if the file is a pipe or FIFO or special file and has fewer than nbyte bytes immediately available for reading. For example, a read() from a file associated with a terminal may return one typed line of data." Does /dev/zero fit into the "special file" category? I think I'm starting to agree with you Eli. =) > > BTW I just discovered I should be checking for SSIZE_MAX, rather than > > INT_MAX. > > Sure, but they are identical in DJGPP. Yep, I was saying that just FYI. Bye, Rich =] -- Richard Dawe [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]