Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!solan1.solan.unit.no!stoeen
From: stoeen@solan.unit.no (Asbj|rn St|en)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Bug in TC findfirst()/findnext()!
Keywords: tc,bug,find,findfirst,findnext
Message-ID: <1991Feb26.173114.7849@ugle.unit.no>
Date: 26 Feb 91 17:31:14 GMT
References: <1991Feb25.192823.18224@ux1.cso.uiuc.edu>
Sender: news@ugle.unit.no
Reply-To: stoeen@solan.unit.no (Asbj|rn St|en)
Organization: Norwegian Institute of Technology
Lines: 22

In article <1991Feb25.192823.18224@ux1.cso.uiuc.edu>, gordon@osiris.cso.uiuc.edu (John Gordon) writes:
|> 	According to the _Turbo_C_Bible_, calls to findfirst() and findnext()
|> are supposed to return filenames that match *both* the given path *and* the
|> given attribute.  However, the above program, which clearly specifies the
|> *directory* attribute (FA_DIREC), finds both directories *and* plain files.
|> Anyone have any comments/fixes/etc?

This is not a bug in TC, but the way DOS handles findfirst() and
findnext(). DOS always returns plain files, *plus* the files that
matches the given attribute. This is the way find..() works in other
languages, so it can't be changed in TC. The _Turbo_C_Bible_ is
probably inaccurate here.

You will always have to check the attribute (0 = plain file).
-- 
			_
Asbjoern Stoeen	       / \     /___
Studpost 188          /___\   //
7034 Trondheim-NTH   / 	   \ / \__
Norway		    	    /     \
(stoeen@solan.unit.no)     /   ___/