Sender: richdawe AT bigfoot DOT com Message-ID: <3A489766.349B3C71@bigfoot.com> Date: Tue, 26 Dec 2000 13:04:38 +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: DJGPP workers CC: Eli Zaretskii Subject: Re: An implementation of /dev/zero for DJGPP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. 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. Does the man page for /dev/zero say what these functions > yield? Unfortunately /dev/zero's man page (FYI zero(4)) does not mention these functions. I will have to take a look at how the null device is handled. > > * /dev/zero will be initialised using the __FSEXT_install_dev_zero() > > function. > > Perhaps it is better not to use the __FSEXT_ prefix. It is taken by > the hooks enumeration. Sure, I've changed it to __install_dev_zero(). BTW there's a device call /dev/full on Linux, which returns zeroes when read, but returns ENOSPC when written to. This could easily be added to the /dev/zero framework. If there are any good uses for /dev/full, then I'll add this. Otherwise I'll just add a note to the /dev/zero sources. [Snipped some of the discussion on checking that context data is present.] > > Why would we get called for a handle that isn't ours? Should we not > > inform the caller that something has gone wrong? > > I don't know. What if some other FSEXT hooked the same handle for > some purpose? For example, the debug support does that. AFAICT you can only have one hook per fd. So if the debug handler hooked an fd and wanted to remain "hidden", it would have to pass FSEXT calls through to the old handler. This means it would have to save a pointer to the old handler's data structure and pass it into the old handler - (sound of penny dropping) ah, but the only arguments you get are the function number and va_list. You could keep the debug FSEXT's presence hidden by do the following in the debug handler install func: save old function and data pointer for fd call __FSEXT_set_data(fd, NULL) to remove association between fd & old data hook fd with debug FSEXT Then in the handler: set data to old data call old handler remove association between fd & old data Does the debug FSEXT work like this? Or does it leave the fd's data pointer alone? > > E.g. memory corruption, bad code? > > If you know that something like that happened, then it's okay to > barf. But I don't think you can know it, at that point. Perhaps a 4-byte (unique) code in the header? > > > If buflen is declared size_t, why do you start failing at INT_MAX? > > > memset would work for up to UINT_MAX, no? > > > > Because 'rv' is an int, we shouldn't overflow the return value. > > ??? But the same problem exists with `_read' and `read', and we still > let DOS do whatever it can. On FAT32 systems, you can potentially > read more than 2^31-1 bytes, right? > > The problem with the return value being signed is a nuisance each > programmer needs to deal with, regardless of FSEXT: a program should > test for the return value being -1; any other value should be cast to > size_t. 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. So, here is what I propose: read() does not have to return the number of bytes asked for. So, when >= INT_MAX is requested, it will return INT_MAX. Since the programmer should be aware that read() may not return everything asked for, this avoids the overflow problem. BTW I just discovered I should be checking for SSIZE_MAX, rather than INT_MAX. > What happens on GNU/Linux systems if you read more than INT_MAX from > /dev/zero? Does it fail? I could not find any information in the Linux man pages, but Unix98 says the following: "If the value of nbyte is greater than {SSIZE_MAX}, the result is implementation-dependent." where 'nbyte' is the buffer size for read()/write(). > I guess open doesn't touch the file times, since it doesn't access the > file's data. Yep, it seems that way. Bye, Rich =] -- Richard Dawe [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]