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 <miesf...@gmail.com> wrote: > 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 using the > current SysFileTree(), which seg faults. Then run the same test using > the new implementation, SysFileTreeB(): > > [miesfeld@Hawk sysFileTree.bug]$ rexx test4.rex > Collecting SysFileTree information > Using SysFileTree() > Segmentation fault (core dumped) > [miesfeld@Hawk sysFileTree.bug]$ > > [miesfeld@Hawk sysFileTree.bug]$ rexx test4B.rex > Collecting SysFileTree information > Using SysFileTreeB() > Enter RexxRoutine5() - SysFileTreeB > 9 *-* rc = SysFileTreeB(ename,"f","BLS") > REX0098E: Error 98 running > /home/miesfeld/work/tools/wc/bug.work/sysFileTree.bug/test4B.rex line > 9: Execution error > REX0647E: Error 98.900: buffer overflow would occur in > recursiveFindFile() at line: 3785; data size: 317 buffer size: 257 > [miesfeld@Hawk sysFileTree.bug]$ > > Here are the 2 questions: > > 1.) My first thought was to raise a condition when a buffer overflow > would occur. This prevents a seg fault and alerts the user to the > problem. But, what I have done is change all the sprintfs to > snprintfs. On Linux, snprintf always writes the null terminator and > of course writes no more than the size specified. So that change is > enough to prevent a seq fault. > > The question is: Should I raise a condition, or just write a truncated line? > > I personally would want a condition raised, because if there was a lot > of data, I might never realize there were truncated lines in the data. > The other thing is, I think that any situation where the condition > was raised, would currently seq fault. So, I don't think there is a > working program now, that would suddenly stop working with a condition > raised. > > 2.) The reason this seq faults on Linux is that the current code uses > a buffer for path of 4096 bytes, (and some other buffers.) But it > also uses some buffers of 255 bytes, and in fact tries to combine the > path buffer, file name, time stamp, and attributes into one of the > small buffers. > > If I changed all the buffers involved to 4096, there would still be > need of using snprint() because it would still be possible to overflow > the buffers. But, it would be much less likely to happen, so less > likely to have a condition raised. > > Should I increase the small buffers to 4096? > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
