[Mesa-dev] [PATCH v2 1/4] mesa: merge bind_xfb_buffers_{base|range}

[Ian Romanick]

On 01/08/2016 04:45 PM, Nicolai Hähnle wrote:
> I've actually been wondering what the deal is with all those different
> boolean types. From what you've written, I'd infer that the intent is
> roughly like:
> 
> 1) GLboolean/GL_TRUE/GL_FALSE for values where the API wants it.
> 2) bool/true/false everywhere else.
> 3) boolean/TRUE/FALSE... who knows?
> 
> ... and this happens to be inconsistent for historical reasons. Does
> that sound right?

We used to use the GL names everywhere because that was the only thing
that existed.

Later, Gallium came along with the intention of supporting non-OpenGL
APIs.  It didn't really make sense to use GL type names in a thing that
wasn't a GL driver.  stdbool.h didn't exist, so they invented
boolean/TRUE/FALSE.

Later still,  C++ for the GLSL compiler stack.  Using bool/true/false
was clearly correct for C++ code.  Around that time we also noticed that
stdbool.h existed.  That made it attractive to used bool and friends for
the C code as well.

There are also some slight semantic differences that make GLboolean very
unattractive.  Ken spent quite a bit of time tracking down a bug in code
like:

    GLboolean x = some_expression();

The reasonable expectation was that if some_expression() was non-zero, x
would also be non-zero.  However, since GLboolean is actually unsigned
char, the above code is really

 unsigned char x = some_expression() & 0x000000ff;

and I think the bug is obvious.  The rules for casting integer to bool
in C99 and C++ are what you expect, so

 bool x = some_expression();

is the same as

 bool x = some_expression() != 0; // or !!some_expression()

which is what was wanted in the first place.

There has been a general trend in the Mesa code to only use GL types for
things that are API facing.  For everything else, "plain" types (e.g.,
int, unsigned), stdint.h types, or stdbool.h types are preferred.

> Thanks,
> Nicolai