[PATCH 1/2] Make parse_static_tracepoint_marker_definition work with multiple static tracepoint definitions

[Simon Marchi]

On 2018-02-18 22:35, Simon Marchi wrote:
> Since I modify the parse_static_tracepoint_marker_definition function 
> in
> the next patch, I wanted to write a unit test for it.  Doing so showed
> that it doesn't handle multiple consecutive static tracepoint
> definitions separated by commas.  However, the RSP documentation [1]
> states that servers may return multiple definitions, like:
> 
>   1234:6d61726b657231:6578747261207374756666,abba:6d61726b657232:
> 
> The problem is that the function uses strlen to compute the length of
> the last field (the extra field).  If there are additional definitions
> in addition to the one we are currently parsing, the returned length
> will include those definitions, and we'll try to hex-decode past the
> extra field.
> 
> This patch changes parse_static_tracepoint_marker_definition to 
> consider
> the case where the current definition is followed by a comma and more
> definitions.  It also adds the unit test that found the issue in the
> first place.
> 
> I don't think this causes any backwards compatibility issues, because
> the previous code only handled single static tracepoint definitions, 
> and
> the new code handles that correctly.

I just pushed these.

Simon