[pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.

[Arun Raghavan]

On Wed, 2011-10-19 at 13:11 +0300, Tanu Kaskinen wrote:
> On Wed, 2011-10-19 at 13:00 +0300, Colin Guthrie wrote:
> > 'Twas brillig, and David Henningsson at 18/10/11 20:56 did gyre and gimble:
> > >> While in general I agree that a boolean is a fine success/failure return
> > >> type, I think in Pulseaudio the convention is to stick just to ints.
> > > 
> > > Hmm. A quick 'grep -r "return TRUE"' of PulseAudio source tree seems to
> > > give enough results to falsify that assumption.
> 
> That gives a big list indeed. But did you check the context? I went
> through quite a lot (but not nearly all) of the output from 'git grep -n
> -e "return TRUE" -e "return FALSE"' and the overwhelming majority of the
> cases were from functions of which whole purpose is to give a yes/no
> answer, or where the function may or may not have a side effect (ie.
> where a "nothing happened" case is not an error). There were some cases
> where "return FALSE" really meant that an error happened, but most of
> those were from the recent format stuff...
> 
> > We're quite happy to return bools on internal stuff. It's just when
> > dealing with client-site/public APIs that we stick to ints.
> > 
> > So as this is an internal function, I think it's fine.
> 
> It's not about having a portable ABI, it's only about the convention
> that errors are reported as negative integers. But if nobody else cares,
> then I'm fine too with using bools.

I usually only code with a negative value return on failure if the
callee can/should distinguish between different types of errors.

-- Arun