Mail Archives: djgpp-workers/2001/01/01/15:24:22
Hello.
Eli Zaretskii wrote:
> So, the first time someone opens /dev/zero, dbg_fsext will be called
> and will register the fact that it was open. The call to _open issued
> from dbg_fsext will then activate the /dev/zero FSEXT. When the call
> to _open returns, dbg_fsext overwrites the value stored by
> __FSEXT_set_function by its own address. From that moment on, the
> /dev/zero fsext will no longer be called when any operation on that
> handle is done.
Thanks for the explanation. If the debug FSEXT only allows the /dev/zero
FSEXT to handle the open operation, then the checks I had on the fd's
context data are OK, I think. IMHO anything that hooks the handling of
/dev/zero & /dev/full is asking for trouble.
If I were being really paranoid, I guess could add checks that the
function associated with the fd is the /dev/zero FSEXT function. If the
/dev/zero handler were not associated with the fd, then it would break and
pass through to the next handler.
> > So, I think the /dev/zero cannot cause trouble with the debug FSEXT.
> > (This is with /dev/zero being installed using __install_dev_zero(),
> > as discussed previously.)
>
> If the debugger itself calls __install_dev_zero, its /dev/zero
> emulation will not work.
>
> I'm not sure this is a grave limitation, but it at least should be
> documented somewhere.
I don't think this is a grave limitation either, since child programs will
be still be able to use /dev/zero, /dev/full.
Where do you think the best place to document this limitation is? In the
source code or in the library documentation?
Well, I think the FSEXT is complete now. I just need to write some fcntl()
and ioctl() tests. Actually, this leads to me to another question - why is
the section containing the FIONBIO ioctl #if 0'd out in sys/ioctl.h? Is
this to prevent some Unixy programs from thinking that we support, e.g.
terminal ioctls?
Bye, Rich =]
--
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]
- Raw text -