[FFmpeg-cvslog] r14362 - trunk/libavcodec/ra288.c

[Reimar Döffinger]

On Thu, Jul 24, 2008 at 06:18:50PM +0200, Michael Niedermayer wrote:
> On Thu, Jul 24, 2008 at 07:04:01AM +0200, Reimar D?ffinger wrote:
> > Hello,
> > On Thu, Jul 24, 2008 at 06:07:50AM +0200, vitor wrote:
> > > Author: vitor
> > > Date: Thu Jul 24 06:07:50 2008
> > > New Revision: 14362
> > > 
> > > Log:
> > > Follow FFmpeg convention of returning negative values on error in eval_lpc_coeffs()
> > 
> > Not that I want to complain, but I do not consider it a convention for
> > internal functions that do not need to return any error codes.
> > At least I will stay with 0/1 where it does not cause problems because
> > it IMO results in more readable conditions...
> 
> IMO it does not, example
> 
> if(foobar(x))
>     kungfoo(y);
> 
> is kungfoo(y) now called if foobar fails or succeeds?

If it succeeds. Unless there is some very special reason, I find this a
horrible way to write it for the < 0 / -1 for error functions since it
reads (when mishandling a programming language as some kind of real
language) as completely the opposite that it does.
So in that case I think it should be written as
if(foobar(x) < 0)

But to be honest, the kind of concept/"convention" that is quite stuck
in my head even if I am unsure if it can be used consequently without
making a whole mess is:
 <  0 : error
 == 0 : failure
 >  0 : success

(now just don't ask me how _exactly_ I define the difference between
"error" and "failure" ;-) ).

> You have to read foobar() to find out unless there is a convention.

Well, a strict convention would have to handle the corner-cases well,
too. E.g. a is_.. function. And what about a is_bad_... function?
Either way, except that I dislike leaving away the < 0 I guess I am
happy as long as at least AVERROR(...) is consistently used where
appropriate ;-)

Greetings,
Reimar D?ffinger