Mail Archives: djgpp-workers/2000/12/28/15:40:43
Hello.
Eli Zaretskii wrote:
>
> Richard Dawe wrote:
> >
> > 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.
[snip]
> Well, you could write a short test program to see what GNU/Linux
> does. We could also say we don't care ;-)
The link(2) man page on Linux lists the following error:
"EPERM The filesystem containing oldpath and newpath does
not support the creation of hard links."
I think this is a valid error. Our /dev/zero resides in a virtual file
system, so this seems appropriate.
The following fcntl() "get" routines seem to be supported: F_GETFD,
F_GETFL. I haven't tried the sets yet, but I presume they are supported.
F_DUPFD is supported. F_GETOWN isn't.
The FIONREAD, FIOGETOWN ioctls aren't supported, returning ENOTTY. FIONBIO
is supported.
I will update the /dev/zero FSEXT appropriately.
> > If there are any good uses for /dev/full, then I'll add this.
DJ's suggestion [in another mail] is good, so I'll add it.
> But my point was more general than the current limitations: I don't
> think that the fact that the handle doesn't have any data is a reason
> to fail the call.
OK, rather than fail, the FSEXT will not do anything - it will be passed
through.
> > Does the debug FSEXT work like this? Or does it leave the fd's data
> > pointer alone?
[snip]
> Btw, since the debug support hooks the handle at startup (its
> initialization routine is declared "__attribute__((constructor))"), it
> is actually the /dev/zero FSEXT which will cause trouble, unless you
> add special code to chain to the previous hook.
Would the /dev/zero hook actually get called, when the debug FSEXT is
present? Surely the debug FSEXT is the first FSEXT, because of the
constructor. So, if a program using the debug FSEXT tries to open e.g.
/dev/zero, it will fail, because the debug FSEXT "knows" nothing about
/dev/zero.
I think I am missing something here - the debug FSEXT is only used within
the debugger, right? Its purpose seems to be to clean up any handles the
child program has created. So the only problem I can see here is that the
child program may not tidy up properly. The debug FSEXT will clean up its
[file] handles.
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.)
> > 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.
>
> Those programs are buggy.
>
> > read() does not have to return the number of bytes asked for.
>
> It doesn't? I've seen gobs of programs which depend on the fact it
> does.
Unix98 says:
"The value returned may be less than nbyte if the number of bytes left in
the file is less than nbyte, if the read() request was interrupted by a
signal, or if the file is a pipe or FIFO or special file and has fewer
than nbyte bytes immediately available for reading. For example, a read()
from a file associated with a terminal may return one typed line of data."
Does /dev/zero fit into the "special file" category? I think I'm starting
to agree with you Eli. =)
> > BTW I just discovered I should be checking for SSIZE_MAX, rather than
> > INT_MAX.
>
> Sure, but they are identical in DJGPP.
Yep, I was saying that just FYI.
Bye, Rich =]
--
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]
- Raw text -