DM> CB> comparable functions if their OS provides it.  It's just that a lot 
f
DM> CB> OSs don't even provide comparable functions, so I felt I needed to 
give
DM> CB> them some.
DM>Hmmm... snippets... dirport.[ch]... ;-)
Nope.  Dirport only provides it on OSs that already have comparable
funtions.  it just deals with naming differences and so on.  My goal in
writing findfirst & findnext was to provide it on OSs that didn't have
anything like it.
As for using dirport for the OSs that do have comparable routines....
No offense to Bob, but I really don't like the way dirport (and a lot of
other things in snippets) are done.  I don't _use_ snippets as is.  I
don't even have snippets actually 'installed'.  I leave it archived and
browse when needed.  I don't do a lot of portability stuff, like he
does, but I prefer to rip out all the other stuff I'm not needing, and
just use the core.
To me, it just seems like every snippet file tries to be totally aware
of every system and compiler.  That seems to clutter things (just try
and read dirport.h....)  I prefer to offer a single interface and
provide seperate headers for each version that needs it.
To extend that to snippets situation, you'd end up with dozens of
compiler specific headers.  One for each compiler on each platform.  And
each header provides all the compatability wrappers / macros that the
rest of snippets uses.  And for every new platform or compiler that
comes out, you'd need to provide one more header.
For something like snippets, that wouldn't really be practical.  For my
D-Flat, it is.  There are only a few areas that really need portability,
and it shouldn't take much for a person to provide what his compiler/OS
needs, and only that platform.  Not even caring about other platforms.
DM>Basically, the structures that the OS has are "global" and "numerous".  
That
DM>is ... you can have multiple searches going on simultaneously.  However, 
tha
DM>means you have to tell the OS you're done so it can reuse the slot later.
Well, the findnext does close the dir, by using closedir().  So, as soon
as the search ends, the OS/2 directory gets closed.  The only other OS
functions that get used are stat() and the localtime, neither of which
would need to be closed.
And findfirst/next itself shouldn't care whether multiple searchs are
going on or not, because all of their data comes from pointers you pass
to it, or local stack data.  In each case, that data would change when a
thread changes, so those functions wouldn't notice.
DM> CB> Are you saying that OS/2 has findfirst/findnext, and it also has a
DM> CB> findclose function?  And that I need to provide a 'dummy' findclose
DM> CB> function to match?  Or does that function actually need to do 
something
DM>It's like fclose - you need to call it.  And I noticed Win32 has the same
DM>feature.  :-)
But I don't see anything in my findfirst/findnext that _needs_ to be
explictly closed.  The only OS structure that is ever open is via
opendir(), readdir(), and closedir().  Those are OS specific functions,
so if the OS needs thread protection, they should provide it.  And my
function does call 'closedir()' to release any stuff that the library
implementation or OS needs to release.
DM> CB> If you can explain it a bit better, I'm willing to see what I can do
DM> CB> before I post my next and hopefully final version of 
findfirst/findnext
DM>See dirport in snippets.  :-)
I'm looking at it right now, but I still don't see anything that _I_
need to do.
Those dirport functions are based on the normal OS/2 versions of
findfirst, findnext, and findclose.  And OS/2's version needs to have
things closed, hence findclose.
But my portable ones don't use those.  They do it directly with the
POSIX functions opendir(), readdir(), closedir().  So, the only OS
structure that _I_ am using is what's being provided by those POSIX
functions.  And I am explictly closing it when I'm done.  If any
additional OS protection needs to be done for those three functions,
then the implementations should already be providing it.
I just don't see anything that my implementation needs to call.  Or
anything it even _can_ call.  I'm already calling closedir() when I'm
done, and the three POSIX dir functions are the only three OS resources
I'm using.
The only thing I can think of, that you might be meaning, is that in the
D-Flat itself, if you chose to use the OS/2 versions, I need to put a
couple of 'FIND_CLOSE' in there in case the user choses to use native
ones instead of the portable ones.  For other OSs, it just expands to an
empty macro, but on OS/2, it expands to the findclose().
And in my portable ones, I should provide an empty findclose() function
in case somebody with an OS/2 program already written wants to use my
portable ones.  Since the already written program will use findclose(),
I need to provide one as well, even though my own findfirst / findnext
don't actually need to be 'closed'.  Due to the nature of the POSIX
opendir(), readdir(), and closedir(), the OS structures will
automatically be closed when the file matching is done.
I'm sorry, but I just don't see what code I need to add.  I can easily
add 'dummy' functions for compatability with OS/2.  I don't mind doing
that at all.  But I just don't see what my 'findclose()' function should
actually _do_.  Since closedir() is already being called, I just don't
see anything else that I can do.
I'm not using OS/2's versions of findopen() and findclose(), so I don't
need to call os/2's findclose() because the OS requires it.  And when
findnext gets done, when it can't find any more matches, it
automatically closes the only OS resource it is using.
I assume you still have the findfirst/findnext code I posted before.  If
you can actually write code to do the findclose(), I'll add it to mine
and repost the whole thing (which I need to do anyway).  But I just
don't understand what mine would need to do.
....  Unless you are meaning I should provide a findclose() in
case the user _stops_ doing more findnext()'s and the directory never
gets closed!  That didn't even occur to me until I'd already written the
rest of the message, because D-Flat does all of the matches, until there
are no more, at which point findnext automatically closes the directory.
This is definetly a bug.  Under DOS it doesn't matter, but the problem
is still there.  Just like if you kept opening new files and never
closed them.  However, this doesn't have anything to do with OS/2 being
a multi-threaded OS, so I don't think this was really what you were
talking about, and why.
void FindClose(struct FFBlk *fb)
{
if (fb->DirPtr) closedir(fb->DirPtr);
fb->DirPtr=NULL;
}
--- QScan/PCB v1.19b / 01-0162
---------------