Mail Archives: djgpp-workers/2000/12/25/03:59:00
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.
- Raw text -