Blair Campbell wrote: > Testers are appreciated
I haven't tested really, but I ran it to see what it did. Afterwards, a look at the source's main() shows the dirs variable has malloc()'s and free()'s not matching either in count or block level conditionals, i.e. first loop malloc()'s are not free()'d and second malloc() in a conditional block is unconditionally free()'d.
The first issue will consume memory in the application unnecessarily, the second is either benign or potentially fatal, depending on whether the compiler follows ISO/ANSI C specs to auto-zero global variables. Compounding the first memory consumption problem, it doesn't look like the code is free()'ing all of its auto-malloc()'ed getcwd[95]()'s. Probably not a critical failing, but possibly significant in a DOS memory-limited/high file count environment .
I don't see how the application will read more than one line of an @ list file in main() without an associated loop construct for the fgets(), but perhaps I misunderstand the functionality and it's not to do so.
A last note from a quick look: the getdcwd95() function is guaranteed to create a buffer overflow. It malloc()'s buf's size based on length of the directory name returned in hbuf from getcurdir95(), then it places information at the beginning of buf, and finally strcpy()'s in the entire hbuf string used to size buf after the additional buf information bytes. That may explain the garbled directory listing displays I saw.
------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
