|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-17 19:54:53
|
Bernhard Simon has reported a problem with "make check" run under an older version of AIX. The stringvar demo caused a segfault. He obligingly traced it to a buffer overflow from a code path using sprintf, which we use only if the system does not provide snprintf. We handle the test case correctly if snprintf is present. This is a general problem, and is mentioned in our TODO file but not in the README or INSTALL files. Simple test =========== manually edit config.h to #undef HAVE_SNPRINTF build gnuplot run test input set format xy "%4096g" plot x With snprintf: util.c:595: Warning: too many digits for format Without snprintf: *** glibc detected *** realloc(): invalid next size: 0x085c64c8 *** Abort or (different test machine): segfault Question ======== Should we have ./configure print out a warning if snprintf is not found? WARNING: Could not find a working snprintf() function. Buffer overflows and segfaults may be triggered by overlong format specifiers provided to gnuplot by the user. Please consider providing snprintf via an external library. Should we issue the same warning at build time? Run time? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <br...@ph...> - 2006-10-17 20:18:00
|
Ethan Merritt wrote: > This is a general problem, and is mentioned in our TODO > file but not in the README or INSTALL files. A note should be added to INSTALL. > Should we have ./configure print out a warning if snprintf is not found? Probably. > Should we issue the same warning at build time? Run time? ./configure time is build time. A message at run time would be excessive and annoying. |
|
From: Daniel J S. <dan...@ie...> - 2006-10-17 20:31:13
|
> Question
> ========
>
> Should we have ./configure print out a warning if snprintf is not found?
>
> WARNING: Could not find a working snprintf() function.
> Buffer overflows and segfaults may be triggered by
> overlong format specifiers provided to gnuplot by the user.
> Please consider providing snprintf via an external library.
>
> Should we issue the same warning at build time? Run time?
I see this comment:
* FIXME: 10 is a purely arbitrary upper limit on args
This could probably be changed so that the arguments are allocated using the heap, making it not limited.
And here is the source of the problem, right?
/* FIXME - this is bad; we should dummy up an snprintf equivalent */
Do we really want to go the route of implementing our own snprintf? That is a fairly low level routine, isn't it? Of course, implementing a crude version wouldn't be too difficult. There is already a search for
next_length = strcspn(next_start,"%");
one can then look for a size specification fairly easily by trying to read what follows the % as an int, if it fails, then assume some size of, oh, 20 characters.
Would there be some way we can use buffered i/o in the case of not having snprintf? E.g., send the data to a file, when all done, check the file size then create a memory buffer big enough to hold the contents, then read it back in? It would be slow on machines that don't have snprintf, but so be it.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-10-17 20:44:17
|
Daniel J Sebald wrote: > one can then look for a size specification fairly easily by trying to > read what follows the % as an int, if it fails, then assume some size > of, oh, 20 characters. I guess implementing the sprintf or snprintf really isn't the critical issue. All we need do is ensure there is enough space, and searching for field width in the format string between two percent signs (%'s) shouldn't be too difficult. Why don't we try to fix the problem using just the sprintf() rather than worry about warning messages? Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-17 20:51:05
|
On Tuesday 17 October 2006 01:41 pm, Daniel J Sebald wrote: > > > > Should we have ./configure print out a warning if snprintf is not > > found? > > > > WARNING: Could not find a working snprintf() function. > > Buffer overflows and segfaults may be triggered by > > overlong format specifiers provided to gnuplot by the user. > > Please consider providing snprintf via an external library. > > * FIXME: 10 is a purely arbitrary upper limit on args That limit has nothing to do with the presence or absence of snprintf. > And here is the source of the problem, right? > > /* FIXME - this is bad; we should dummy up an snprintf equivalent */ That's one place, one that actually has a comment noting the problem. But there are other places as well. > Do we really want to go the route of implementing our own snprintf? The suggestion in TODO is to find one with a compatible license. I did a bit of poking around on the web and found one with a BSD license and reference to one with an Apache implementation. But I have neither time nor inclination to deal with evaluation of licensing issues if we were to include these as source. The current code does the right thing on any system modern enough to provide snprintf. I think it is sufficient to give a warning when gnuplot is built on a legacy system that doesn't. > implementing a crude version wouldn't be too difficult. You might be surprised. The versions I found ran to hundreds of lines of code. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |