delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/12/25/03:59:00

Date: Mon, 25 Dec 2000 10:57:25 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <richdawe AT bigfoot DOT com>
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: <Pine.SUN.3.91.1001225105646.18547E-100000@is>
MIME-Version: 1.0
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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019