[Mesa-dev] Mesa (master): mesa: Validate assembly shaders when GLSL shaders are used

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Paul wrote:
> On 10/12/2010 07:49 PM, Ian Romanick wrote:
>> Brian Paul wrote:
>>>> -
>>>> +#include<stdbool.h>
>>>
>>> Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be
>>> consistent?  It wouldn't surprise me if stdbool.h isn't present on one
>>> platform or another.
>>
>> If possible, I'd prefer not.  All of the GL types are ugly anachronisms
>> from the early 90's when there were no standard, cross-platform sized
>> types.  We've had those types for over a decade, and not using them
>> makes the code more obtuse.  To be perfectly honest, I'd love to see
>> them removed from OpenGL altogether.
> 
> My concern here is people will get lazy and just use int everywhere.
> Using GL types such as GLuint, GLint, GLboolean and GLbitfield convey
> useful information about the variables declared with those types.

GLuint -> unsigned
GLint -> int
GLboolean -> bool
GLbitfield -> GLbitfield
GLclampf -> GLclampf
GLenum -> GLenum

There are a few GL types that actually have useful semantic information.
 The others were just ways to request types of a specific size (e.g.,
GLint must be a 32-bit integer).  With inttypes.h and stdbool.h those
types no longer serve any purpose.  They just make code that uses OpenGL
look different from code that doesn't use OpenGL.

> For example, if I see "int buffers_used" I have to wonder if it's really
> a boolean or a bitfield or a count (and what if it's negative?).  I
> don't have that problem if the GL types are used.

GLint vs. GLuint doesn't provide any advantage over int vs. unsigned.
Looking at the number of 'comparison between signed and unsigned integer
expressions' warnings (over 600 in my build) in Mesa, it's pretty clear
that we're doing it very wrong anyway.

> We should keep the "write once, read many times" principle in mind.
> 
> 
>> We already have stdbool.h in the Mesa tree for platforms that lack it.
>>
>> Moreover, we're using bool/true/false in all of the C++ code.  Even as a
>> long time OpenGL programmer I find bool/true/false infinitely more
>> natural than GLboolean/GL_TRUE/GL_FALSE.
> 
> Well, I like consistency and it looks a bit messy to mix GLboolean and
> bool in neighboring code.
> 
> C++ has had its bool type for a long time I have no problem with using
> it there.  GLboolean would look out of place in the GLSL compiler code.
> 
> 
>> Either way, we should resolve this soon.  All of the EXT_sso work I've
>> been doing using stdbool.h, so I'd like to know if I need to go back and
>> change all of that.
> 
> I'd prefer GLboolean but I also don't want to cause you a lot of
> inconvenience in your work.
> 
> Some O.S. projects have a pretty rigid coding style and I like the
> consistency of that.  I'd actually like to have that in Mesa but I also
> don't want to spend my time nagging people about their style.

Yeah, pretty much all large projects have more rigid coding style
guidelines.  I think that's a good thing.  They also adapt over time.
The Linux kernel coding style isn't the same today as it was 5 years
ago, for example.  Part of what makes it work in other projects is a
more rigid review process.  Much fewer people have commit rights, and
changes from other people have to go through those few gatekeepers.

Maybe it's time to at least work out what we would want the coding style
to be.  A process for enforcing it can be derived later.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky3dfkACgkQX1gOwKyEAw9fDgCfTX4M3xrBLcQJsJ0uxLXiXEyh
M/YAnih4bYllaud0aJXPSEydx9lGuzSF
=swXV
-----END PGP SIGNATURE-----