Date: Tue, 12 Jan 1999 17:49:34 +0100 From: Laszlo Molnar To: djgpp-workers AT delorie DOT com Subject: Re: djgpp 2.02 + perl + glob Message-ID: <19990112174934.W29345@duna54> References: <19990112094755 DOT O29345 AT duna54> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i In-Reply-To: ; from Eli Zaretskii on Tue, Jan 12, 1999 at 11:24:57AM +0200 Reply-To: djgpp-workers AT delorie DOT com 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