[pulseaudio-discuss] pa_modargs interface question

[Tanu Kaskinen]

On Sun, 2016-07-03 at 21:43 +0200, Ulrich Eckhardt wrote:
> Hi!
> 
> Looking at the various functions in modargs.h and their concrete
> behaviour. What I find odd there is that the functions return an
> errorcode (an int, wouldn't it be worthwhile to use a typedef for that?)

A typedef might be good, if the error code actually contains some
useful information, but if it's just -1 for failure and 0 for success,
I don't think a typedef would be beneficial. Once you know that
failures are always reported as negative integers and successes are
always reported as non-negative integers, I don't think the readability
of the code suffers from using plain ints.

We do have pa_error_code_t that perhaps could be used as the return
type for functions that return meaningful error codes. pa_error_code_t
values are positive, though, so maybe that's not so good after all...

(I would personally prefer something like what GLib does for reporting
errors, because it allows better error messages than just a simple
error code, but maybe it's too late to change the convention at this
point. And this is only relevant when reporting errors to clients,
because at server side we can always print an informative message to
the log.)

> but that they don't always return an error when extracting an argument
> fails. In particular when the argument is not present, they return
> success nonetheless.
> 
> At first, I thought that was a bug. However, that peculiar behaviour is
> present in every pa_modargs_get_value_* function, and I rather think
> that it's intention. The intention is that the supplied pointer to the
> value is supposed to give both the default value and the output
> value, right?

Right. Considering a missing modarg an error would only cause trouble,
because almost every modarg is optional.

-- 
Tanu