[MPlayer-dev-eng] [PATCH] vo_macosx: option to set shared buffer name to allow multiple instances

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Wed Dec 10 15:52:13 CET 2008


On Wed, Dec 10, 2008 at 03:23:26PM +0200, Uoti Urpala wrote:
> On Wed, 2008-12-10 at 10:26 +0100, Reimar Döffinger wrote:
> > On Tue, Dec 09, 2008 at 03:20:58PM +0100, Adrian Stutz wrote:
> > > 1: vo_macosx_subopt_parsing.patch
> > > Changes vo_macosx's custom subopt parsing to subopt_parse().
> > 
> > One minor comment: the subopt parser will always use 0/1 for bool
> > variables, so using "false" might not be such a good idea (it adds the
> > implicit assumption that "false" is always 0). But if you think the
> > readability advantage is worth it you can of course leave it in.
> 
> In C "false" is always 0, and that's something you _should_ assume.

Huh? There is no "bool" and no "false" in C, and also I don't think you
should  _never_ _ever_ assume anything unless you have a reason.
Readability may be such a reason, and I already said so.

> doubt that differs in Objective-C (I assume the "false" used here is
> part of Objective-C).

I admit I have no idea about Objective-C (I forgot we were not talking
about plain C here).
Anyway, feel free to ignore my comment, but using an Objective-C "false"
when calling a C API just feels a tiny bit wrong to me.

> Choosing whether to write "0" and "1" or
> "false" and "true" is always only about code readability and making the
> semantics obvious, and much of the time that is also true about choosing
> whether to make the type of a variable "bool".

As said, that can hardly be true for a plain C program since anything
using "true", "false" or "bool" is simply not going to compile unless
you define them yourself (which means some idiot can define them wrong).

Greetings,
Reimar Döffinger



More information about the MPlayer-dev-eng mailing list