Mail Archives: djgpp-workers/2000/12/26/07:41:32
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/ ]
- Raw text -