[HOpenGL] two bugs in ShaderObjects.hs

Sven Panne svenpanne at gmail.com
Tue Jan 20 15:24:48 UTC 2015


2015-01-20 15:28 GMT+01:00 Claude Heiland-Allen <claude at mathr.co.uk>:
> Ok, I do understand this philosophy,

Just to be clear: This is basically not *my* philosophy, but the one
used in OpenGL itself. It is partly explained in the OpenGL spec
itself, partly by the fact that almost no OpenGL call has a return
value to indicate success/failure (unlike e.g. the *nix system calls).
This is probably an artifact from the time of the buffer-less fixed
rendering pipeline, when you had tons of OpenGL calls frame and any
kind of error checking would have been prohibitively costly. If OpenGL
would be designed today, things would look different, I guess.

Anyway, in my experience fighting against any kind of design
philosophy in your program is a lost battle in the end, and that's why
the OpenGL binding is like it is.

> but one last suggestion: replace 'alloca' with 'with 0' to at least avoid reading uninitialized memory when
> the application programmer makes a mistake (0 should be a sensible default
> in most cases I imagine).  If git patches for this replacement would be
> accepted, I would be willing to submit them for as many places in the
> binding as I can find.

I think it might make sense for the places where the value is actually
unmarshaled, so the unmarshal function might call "error" for unknown
values. For basic types like GLfloat/GLint/... it doesn't really make
sense and doesn't hurt: The value is just undefined, and 0 is not
really better. In our concrete case of "shaderVar", poking 0 into
"buf" first would be OK then. If you like, you can prepare a GitHub
pull request for this and other sensible places. That's easier than
sending patches around by hand and comment them. Create a GitHub
account, fork the OpenGL repo, upload a fix and send this as a pull
request, it's only a few clicks... :-)


More information about the HOpenGL mailing list