ralph wrote: > Hi, > > I've been fixing some buffer-overflow bugs which can cause SIGSEGV. > I think I've done the fixes and want to add tests to spot regressions. > Key to the test is the size of the buffer, typically NMH_BUFSIZ. > > $ G g -B4 'define NMH_BUFSIZ' > h/mh.h-/* > h/mh.h- * This macro is for use by scan, for example, so that platforms > with > h/mh.h- * a small BUFSIZ can easily allocate larger buffers. > h/mh.h- */ > h/mh.h:#define NMH_BUFSIZ max(BUFSIZ, 8192) > $ > > I see some tests already hard code 8192. Alternatives include: > > - Adding a trivial test/nmhbufsiz.c which prints it but none of the > existing test-support C files use NMH code AFAICS > - Having mhparam(1) print it, but it currently doesn't list internal > constants like that, even with ‘-debug’. > > If no one objects or there's no better idea then I'll plump for the > first option.
I see no reason to introduce a new executable for this. It seems to me that it's a pretty natural fit for mhparam -debug, which already displays build-oriented information. If we expose this, can we limit the scope of: Testing inc of files with various alignments of eom marker with buffer size... to make it run a little faster? :-) paul =---------------------- paul fox, [email protected] (arlington, ma, where it's 57.4 degrees)
