[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Obtaining NMH_BUFSIZ in a Test.
From: |
Paul Fox |
Subject: |
Re: Obtaining NMH_BUFSIZ in a Test. |
Date: |
Tue, 11 May 2021 11:22:02 -0400 |
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, pgf@foxharp.boston.ma.us (arlington, ma, where it's 57.4 degrees)