> There reportedly was an issue [2] regarding stack usage with the Open Watcom > built binaries. > Skimming over the source, especially [3], indicates that this may use A LOT of > stack space depending on what value MAXPATH is defined to be (it is 260 for my > Open Watcom installation). That is approaching 2k of stack per recursive call > of xcopy_files.
If a program requires an extremely large chunk of memory to store something, especially if it needs to do it repeatedly (as would be the case in recursive scenarios), the stack is the wrong place to store it. Stacks are for relatively small chunks of data. It's also possible that this really isn't a stack size problem (even though it appears to be), but rather something incorrectly being identified as a stack issue. The fact that it works on some machines and not others (assuming using the same source disk) makes me think it may not really be a stack issue, at least not directly. Jerome says all the machine have a network driver of some sort, but I suspect they aren't all using the same driver (or NIC), and maybe not even the same EMM/XMM (if there is even one loaded). I was also thinking it could possibly be a problem with the source disk (like cross-linked files that somehow end up in a loop), but that wouldn't be the case if the same source disk is used and he even reformatted the destination disk. It might also might make a difference whether or not an LFN driver is installed. > So the stack size will likely have to be increased to make it work with a > reasonably large directory nesting level. Independent of any possible errors, > the 8K mentioned in the commit may simply not be enough. Heap allocation may > be > considered for these quantities of memory... Exactly. This much memory should use something other than a stack, and a heap might be a good solution. There could also be some combination of a heap (or temporary file or something like that) and a stack (which could just store a pointer). _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
