[redland-dev] Bug in raptor_vsnprintf()

[John Emmas]

I've found a bug in raptor_vsnprintf2() (raptor2).  Where should I report it?  For anyone who's curious, here's the problem:-


int
raptor_vsnprintf2(char *buffer, size_t size,
                  const char *format, va_list arguments)
{
  size_t len;

  RAPTOR_ASSERT_OBJECT_POINTER_RETURN_VALUE(format, char*, 0);

#ifdef CHECK_VSNPRINTF_RUNTIME

  if(vsnprintf_is_c99())
    VSNPRINTF_C99_BLOCK(len, buffer, size, format, arguments) ;
  else
    VSNPRINTF_NOT_C99_BLOCK(len, buffer, size, format, arguments) ;

#else

#ifdef HAVE_C99_VSNPRINTF
  VSNPRINTF_C99_BLOCK(len, buffer, size, format, arguments) ;
#else
  VSNPRINTF_NOT_C99_BLOCK(len, buffer, size, format, arguments) ;
#endif

#endif
  
  return RAPTOR_BAD_CAST(int, len);
}

Note that 'len' is uninitialised when it gets passed to either of the macros (VSNPRINTF_NOT_C99_BLOCK, in my case).  In abbreviated form, the macro translates to this code:-

#define VSNPRINTF_NOT_C99_BLOCK(len, buffer, size, format, arguments)   \
  do {                                                                  \
    if(!buffer || !size) {                                              \
      /* This vsnprintf doesn't return number of bytes required */      \
      size = 2 + strlen(format);                                        \
      len = -1;                                                         \
      /* Do some other stuff (includes setting */                       \
      /* the correct value for 'len')          */                       \
    }                                                                   \
                                                                        \
    if(buffer)                                                          \
      vsnprintf(buffer, len, format, arguments);                        \
  } while(0)

The variable 'len' gets passed to vsnprintf() - but if 'buffer' and 'size' both started off with nonzero values, 'len' will contain a garbage value.

Hope that makes sense.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librdf.org/pipermail/redland-dev/attachments/20120522/de29265a/attachment.html>