Mail Archives: djgpp-workers/1999/01/12/13:21:43
On Tue, Jan 12, 1999 at 11:24:57AM +0200, Eli Zaretskii wrote:
> > The problem: when a new handle is
> > allocated, it is not opened, but dup()-ed in djgpp 2.02.
> Right. This change was done to prevent fsext from failing when it
> exhausts the max count of handles determined by the FILES= directive.
> `dup' is not limited by FILES=, and so can go up to the maximum of 255
> handles that DOS allows.
> > It would work
> > perfectly if the file pointer would be set to 0, ie an lseek(..,0,0)
> > should be added after dup() IMHO.
> Can you elaborate why is this needed? Is this something specific to the
> way Perl uses fsext, or do you think this is a general problem, and why?
Ok, here is how perl uses the fsext: when a globbing request arrives I
call glob(), copy all filenames to an array and allocate the fsext
handle. Next time a read request arrives on the handle, and I copy the
requested bytes to the user from my buffer. The file pointer on the
handle is updated of course. If a new glob() request arrives and I
allocate (ie. open) another handle, its file pointer won't be set to 0
because of dup. So when a reading request arrives on the second handle
I will possibly pass garbage to the user.
I think this is a general problem, because when a file handle is
allocated (opened) I would expect its file pointer set to 0. Or am I
missing something?
> Don't forget that lseek itself might be hooked by the fsext, btw.
Yes, this might be a problem. But not using it is a bigger one IMO.
Laszlo
- Raw text -