_findnext always gives Access Violation
garrettc
After I call _findfirst, I call _find next, such as listed below. No matter
what I do, the _findnext always produces an Unhandled Exception, Access
Violation. It never gets beyond the 'while' initialization. I've tried
seperating _findnext on a line by itself, but no help. Also, hFile seems to
be always 0 (zero), is that right?
Any help?
Thanks,
garrett curtis
gcu...@cinci.rr.com
chdir(dirnames[c]);
if(hFile=(_findfirst("*.*",&fileinfo)) == -1L )
{
printf("*** No files in this directory: %s\n",dirnames[c]);
continue;
}
if((strcmp(fileinfo.name,".") != 0 ) && (strcmp(fileinfo.name,"..") != 0 )) {
filenames[0]=malloc(512);
strcpy(filenames[0],fileinfo.name);
fcount=fcount+1;
}
while( _findnext( hFile, &fileinfo ) == 0 ) {
sprintf(fullname,"%s/%s",dirnames[c],fileinfo.name);
if(is_on_omitlist(omitlist,omitcount,fullname)) continue;
sprintf(fullname,"%s/%s",dirnames[c],fileinfo.name);
get_attributes(fullname,lineitem);
write_line(outfp,lineitem);
}
Brian Muth
hFile=(_findfirst("*.*",&fileinfo)) == -1L )
In other words, hFile is set to either true (ie. _findfirst("*.*", &
fileinfo) is equal to -1) or false (_findfirst("*.*",&fileinfo) is not equal
to -1).
In your case it is false.
You need to move your parentheses around....
Brian
garrettc
Now it works great.
Thanks a ton!
garrettc
Alexander Grigoriev
'if' clause. One can see it a lot in old *NIX sources, though. Saving line
breaks?
"Brian Muth" <bm...@mvps.org> wrote in message
news:%23zC8tkG...@TK2MSFTNGP15.phx.gbl...
garrettc
This one is just one of those things you do but really didn't think about. In
fact, I usually do an assignment on a line prior to testing the result. In
this case I fell prey to old habits. Hey, lesson learned. I figured the
problem was something simple, but sometimes you need someone to see it for
you.
I appreciate all your comments. Thanks
garrett
Jerry Coffin
al...@earthlink.net says...
> It's always a bad style to do an assignment and check the result in the same
> 'if' clause. One can see it a lot in old *NIX sources, though. Saving line
> breaks?
I disagree. In fact, quite a few actions should be combined with
checking whether they succeeded or failed. For one example, consider
opening a file. The correct for is NOT like this:
FILE *f=fopen("somename","r");
/* should be:
if ( f == NULL)
// it didn't open
*/
but like this:
if ( NULL == (f=fopen("somename", "r")))
// if didn't open
Likewise (for another example) with malloc -- calling malloc and
checking that it returned a non-null pointer should be combined into
a single operation:
if ( NULL == (x=malloc(sizeof(whatever))))
// malloc failed.
As to why these should be combined in this fashion: the code should
accurately reflect the thinking and intent of the programmer. With a
function like this, checking the return value is not (and should
never be thought of as) a separate operation that takes place after
you call the function. Rather, it should be thought of (and coded as)
a mandatory PART OF calling the function.
Nearly _everybody_ who separates the two eventually ends up (through
accident, forgetfulness, laziness, or whatever) calling a function
like this and skipping over checking its return value at least once
in a while. As long as you code the function call as part of checking
the return value, it's impossible to skip over this essential step.
Calling findfirst is the same way -- checking the return value should
neither be thought of, nor coded as, a separate step that takes place
after the function is called. It is, and should be coded as, a
mandatory, integral part of calling the function.
--
Later,
Jerry.
The universe is a figment of its own imagination.
garrettc
file read methods (and others) is the way to go, and what you would typically
see in open source code. In my 15 yrs of Unix programming it has been the
norm.
Sometimes it is instructive to separat the statement for debugging purposes.
But for normal program flow, the combined statement will be more germain to
program flow.
garrett