When varlink_object_new_from_json is fuzzed it receives a lot of bogus json strings and clutters stderr with messages like "2 != 4" instead of just returning errors. Given that it's the only place where fprintf is used like that it seems it was left there accidentally and can probably be safely removed to make the API more consistent in general.
It should make it easier to fuzz the library and other than that it should also make it possible to compile libvarlink on some architectures without compiler warnings like
../lib/scanner.c:628:49: warning: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
fprintf(stderr, "%ld != %ld\n", utf8_len, size);
~~~ ^~~~~~~~
%zu
../lib/scanner.c:628:59: warning: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
fprintf(stderr, "%ld != %ld\n", utf8_len, size);
~~~ ^~~~
%zu
When varlink_object_new_from_json is fuzzed it receives a lot of bogus json strings and clutters stderr with messages like "2 != 4" instead of just returning errors. Given that it's the only place where fprintf is used like that it seems it was left there accidentally and can probably be safely removed to make the API more consistent in general.
It should make it easier to fuzz the library and other than that it should also make it possible to compile libvarlink on some architectures without compiler warnings like