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

[Uoti Urpala]

On Wed, 2008-12-10 at 15:52 +0100, Reimar Döffinger wrote:
> 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:
> > > 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

#include <stdbool.h>
They're not keywords for the sake of compatibility with old programs
which could have used them as normal identifiers. The standard header
stdbool.h defines "true" and "false", and allows using "bool" instead of
the keyword "_Bool". They are C just as much as "printf" is.

> should  _never_ _ever_ assume anything unless you have a reason.
> Readability may be such a reason, and I already said so.

IMO assuming that "true" and "false" are 0 and 1 is at about the same
level as assuming that relational operators produce 0 and 1. A program
could use some different perverse definition for them, but then again it
could #define any keyword to a different value too.

> > 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.

IMO viewing them as completely separate types isn't suited for C. And if
you view "false" and "true" as having the same technical effect as "0"
and "1" but giving more information about the intentions of the
programmer then there is no more than reason to worry about 'another
language's "false"' than about 'another language's "0"' (at least as
long as that language does not have significantly different semantics).

> > 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).

As above, you should #include <stdbool.h>.