Date: Mon, 25 Dec 2000 10:57:25 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe cc: djgpp-workers AT delorie DOT com Subject: Re: An implementation of /dev/zero for DJGPP In-Reply-To: <3A468DFE.79156B94@bigfoot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 24 Dec 2000, Richard Dawe wrote: > > It's okay to leave these two out, since dup/dup2 are always supported > > for FSEXT handles. (Hmm, perhaps the same ``trick'' will work for > > fcntl and friends?) > > Currently link(), fcntl(), ioctl() are just passed through unprocessed. > Will the pass through will work OK (perhaps), because these calls end up > being applied to the NUL device (since __FSEXT_alloc_fd() returns an fd > linked to NUL)? 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? > * /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. > > > /* Get context */ > > > data = (DEV_ZERO_DATA *) __FSEXT_get_data(fd); > > > if (data == NULL) { > > > errno = EBADF; /* TODO: Right error? */ > > > *rv = -1; > > > break; > > > } > > > > I don't the last snippet is right: this condition can happen if we > > somehow are called for a handle that isn't ours. So I think you > > should simply return without handling the call; failing the call seems > > a bit too drastic. > > 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. > 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. > > > /* Is the specified length bigger than the max return value? */ > > > if (buflen > INT_MAX) { > > > errno = EINVAL; /* TODO: Right error? */ > > > *rv = -1; > > > break; > > > } > > > > 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. What happens on GNU/Linux systems if you read more than INT_MAX from /dev/zero? Does it fail? > > Shouldn't the open hook also update the access time? (I'm not sure > > which Unix system calls update atime.) > > FYI here's what the stat(2) man page says on RedHat Linux 6.2 (man-pages > 1.28-6): Okay, thanks. I guess open doesn't touch the file times, since it doesn't access the file's data.