]> git.evergreen-ils.org Git - OpenSRF.git/commit
Patch from Scott McKellar:
authorerickson <erickson@9efc2488-bf62-4759-914b-345cdb29e865>
Mon, 17 Nov 2008 02:56:40 +0000 (02:56 +0000)
committererickson <erickson@9efc2488-bf62-4759-914b-345cdb29e865>
Mon, 17 Nov 2008 02:56:40 +0000 (02:56 +0000)
commit63670107c380893fc62be356d9700c23b7776c96
tree162e9a7902414aed4af435a1842228b00a9839ef
parent7e828353a556e9baf2a2c3e4dbdff12e176871c7
Patch from Scott McKellar:

This patch fixes a bug in the OSRF_BUFFER_ADD_CHAR macro.

Like the corresponding buffer_add_char function, this macro appends a
specified character to a growing_buffer.  Unlike the function, however, the
existing version of the macro does not also append a terminal nul.

This bug had gone unnoticed because, most of the time, the rest of the
buffer is already filled with nuls, left over from the initial creation of
the growing_buffer.  I stumbled across the problem when, in the course of
writing a test harness for some other changes, I called buffer_reset()
in order to reuse an existing growing_buffer instead of destroying and
re-creating it.

With debugging turned on, buffer_reset() fills the buffer with exclamation
points, leaving a nul only in the very last byte.  Later, if we use
buffer_add() or buffer_fadd() to extend the string stored in the
growing_buffer, it uses strcat() to append the new characters.  The result
is a buffer overflow.

Actually buffer_reset() should place a nul in the first byte of the buffer.
Tomorrow I shall submit a patch to that effect.

git-svn-id: svn://svn.open-ils.org/OpenSRF/trunk@1494 9efc2488-bf62-4759-914b-345cdb29e865
include/opensrf/utils.h