Message-ID: <008901c15d6b$939e6640$b05424d5@zephyr> From: "Eric Botcazou" To: "DJGPP workers" References: Subject: Re: _findfirst() patch (2) Date: Thu, 25 Oct 2001 17:39:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Reply-To: djgpp-workers AT delorie DOT com > I'd say lets change all the functions in this family to return EFAULT. Ok for EFAULT :-) > > No, of course, but that's consistent with the errno code since > > _doserr_to_errno(5) = EACCES. > > I don't think this consistency matters too much. It's more important to > tell the calling application something intelligent about why did the > function fail. Is it really more intelligent to return 2 (File not Found) or 3 (Path not Found) when the path pointer or the result pointer are invalid, rather than 9 (memory block address invalid) that gives EFAULT ? > The reason for this request is, as I explained, that it makes it easier > to review the changes. There are no other principles beyond that. I > agree that sometimes the old code could be made more readable, but I'm > asking not to mix real changes with cosmetic ones. Another reason why I did that is I found that dos/dir/findfirst.c and dos/dir/findnext.c are better written than dos/compat/d_findf.c and dos/compat/d_findn.c; since I almost entirely discarded the former files, I choosed to put their materials in the latter. > > I could turn the question... > > See dos/dir/findfirs.c and dos/dir/findnext.c . > > Consistency again. > > It's arguable, I think: _dos_findfirst _did_ use sizeof. Yes, but the other solution (that of dos/dir/findfirs.c and dos/dir/findnext.c) is better. > > Why ? You must not pass an invalid handle to the function. > > Even if an invalid handle causes the user's disk to be wiped out? ;-) Hey, that's the price to pay for writing bad code ! ;-) Ok, you're right, I'll add a check. > > Copy-pasted from dos/compat/d_findf.txh > > Yes, there are places in the docs where incorrect markup is used. That > doesn't mean we should add new ones. Obviously not, but that makes it a little hard to pick the right one :-) > > Why ? the user must call _findclose() in all cases. findnext() doesn't > > mention ENMFILE either and it's exactly the same situation. > > No, findnext doesn't require the application to close the handle, it does > that itself. So in the case of findnext, if the application is not > written to handle ENMFILE specially, it will report an error, but with > _findnext, the application will leak search handles (or memory). I don't see why, since _findclose() must be called in all cases: as soon as _findnext() returns a non-zero value, _findclose() is called, then it's up to the application to decide which errno code to handle (exactly like with findnext). > > Copy-pasted from dos/dir/findfirs.c and dos/dir/findnext.c > > Using it instead of a mere sizeof() saves a lot of bytes. > > I don't understand: why does it save a lot of bytes? sizeof isn't a > function. Instead of transfering the whole structure to the DTA (~290 bytes), you transfer only the meaningful part (~40 bytes). -- Eric Botcazou ebotcazou AT multimania DOT com