delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/10/25/11:43:43

Message-ID: <008901c15d6b$939e6640$b05424d5@zephyr>
From: "Eric Botcazou" <ebotcazou AT libertysurf DOT fr>
To: "DJGPP workers" <djgpp-workers AT delorie DOT com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1011025153806 DOT 4816O-100000 AT is>
Subject: Re: _findfirst() patch (2)
Date: Thu, 25 Oct 2001 17:39:42 +0200
MIME-Version: 1.0
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019