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
#define OSRF_BUFFER_ADD_CHAR(gb, c)\
do {\
if(gb) {\
- if(gb->n_used < gb->size - 1)\
+ if(gb->n_used < gb->size - 1) {\
gb->buf[gb->n_used++] = c;\
+ gb->buf[gb->n_used] = '\0';\
+ }\
else\
buffer_add_char(gb, c);\
}\
char* va_list_to_string(const char* format, ...);
-/* string escape utility method. escapes unicode embeded characters.
+/* string escape utility method. escapes unicode embedded characters.
escapes the usual \n, \t, etc.
for example, if you provide a string like so: