[Mesa-dev] [PATCH 01/11] mesa: Returns a GL_INVALID_VALUE error on several glGet* APIs when max length is negative

Erik Faye-Lund kusmabite at gmail.com
Mon Jan 19 04:31:43 PST 2015


On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev <elima at igalia.com> wrote:
> The manual page for glGetAttachedShaders, glGetShaderSource, glGetActiveUniform and
> glGetActiveUniform state that a GL_INVALID_VALUE is returned if the maximum length
> argument is less than zero. For reference, see:
> https://www.opengl.org/sdk/docs/man3/xhtml/glGetAttachedShaders.xml,
> https://www.khronos.org/opengles/sdk/docs/man31/html/glGetAttachedShaders.xhtml,
> https://www.opengl.org/sdk/docs/man3/xhtml/glGetShaderSource.xml,
> https://www.khronos.org/opengles/sdk/docs/man31/html/glGetShaderSource.xhtml,
> https://www.opengl.org/sdk/docs/man3/xhtml/glGetActiveUniform.xml,
> https://www.khronos.org/opengles/sdk/docs/man31/html/glGetActiveUniform.xhtml,
> https://www.opengl.org/sdk/docs/man3/xhtml/glGetActiveAttrib.xml,
> https://www.khronos.org/opengles/sdk/docs/man31/html/glGetActiveAttrib.xhtml.
>
> This fixes 4 dEQP test:
> * dEQP-GLES3.functional.negative_api.state.get_attached_shaders
> * dEQP-GLES3.functional.negative_api.state.get_shader_source
> * dEQP-GLES3.functional.negative_api.state.get_active_uniform
> * dEQP-GLES3.functional.negative_api.state.get_active_attrib

These tests are about GLES3, but I cannot find such behavior specified
in the OpenGL ES 3.0 specification for GetAttachedShaders nor
GetProgramBinary. I stopped checking after those two, because I felt I
saw a pattern ;)

The man pages you linked to are for desktop-OpenGL, which *does*
specify such an error; OpenGL 4.5 spec says "An INVALID_VALUE error is
generated if maxCount is negative" about GetAttachedShaders (and a
similar for GetProgramBinary()).

However, the GLES 3 man pages also list such an error:
https://www.khronos.org/opengles/sdk/docs/man3/html/glGetAttachedShaders.xhtml

Generally speaking, the manual pages are not considered to dictate
behavior, only to be a programmer convenience. And they have
historically been full of errors. However, since desktop GL *does*
specify these errors *and* the man-pages document them, this does look
like a spec-error for GLES 3 to me. But I think we should get a
clarification from Khronos before assuming so, otherwise we won't be
in conformance. Ian, any thoughts?


More information about the mesa-dev mailing list