I've got a lengths of bytes that I need to read from the tvb and render as a hex string that are / may be longer than MAX_BYTE_STR_LEN which is defined as 48. I do not need the actual bytes from the tvb after I render it as a hexstring.
I the natural use here would have been tvb_bytes_to_str, but that calls:
return bytes_to_str(allocator, ensure_contiguous(tvb, offset, len), len);
And bytes_to_str is what limits the results to a length of MAX_BYTE_STR_LEN.
My approach here is to create my own bytes_to_str that renders and returns a hexstr for the full byte array that I provide.
ensure_contiguous is not publicly exposed... at least not directly.
tvb_get_ptr appears to be a public wrapper for ensure_contiguous
const guint8*
tvb_get_ptr(tvbuff_t *tvb, const gint offset, const gint length)
{
return ensure_contiguous(tvb, offset, length);
}
There seems to be consternation using tvb_get_ptr though. Is there a compelling reason to allocate memory, read and copy the data pointed to by ensure_contiguous, then use that new space to read the data in order to render the hexstring vs. just rendering the hexstring from the ptr returned from ensure_contiguous directly like bytes_to_str does?
Jason
