After going through the code for SysFileTree() on Unix, it was
apparent it would be easy for it to seq fault. I've reimplemented
SysFileTree on both Windows and Unix using the new APIs and cleaned up
the areas where it was possible to crash.
Here is output on a Fedora Linux. First run the test
I'm definitely in favor of enlarging the buffers. My personal
preference would be no error or truncation, but rather detect if
truncation is going to occur (or has occurred) and allocate a
temporary buffer of sufficient size.
Rick
On Wed, Jul 25, 2012 at 1:59 PM, Mark Miesfeld
Another approach is for the function to handle the problem: try a fixed small
buffer, if that fails, [m]allocate a bigger one (2x size). Repeat until it gets
silly, in which case report 'out of memory'.
The 'allocate a bigger one' can also be done on the stack by using a proxy call
which is
On Wed, Jul 25, 2012 at 11:13 AM, Mike Cowlishaw m...@speleotrove.com wrote:
Another approach is for the function to handle the problem:
Okay, well both Rick and Mike's answer is pretty much the same,
allocate a bigger buffer when needed.
Good thing I asked, I didn't really consider that.
