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

[Erik Faye-Lund]

On Tue, Jan 20, 2015 at 3:54 AM, Ian Romanick <idr at freedesktop.org> wrote:
> On 01/19/2015 04:35 AM, Erik Faye-Lund wrote:
>> On Mon, Jan 19, 2015 at 1:31 PM, Erik Faye-Lund <kusmabite at gmail.com> wrote:
>>> 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?
>>
>> By the way, this error is also properly defined for OpenGL ES 3.1, so
>> I'm feeling even more confident that it's a spec-bug in OpenGL ES 3.0.
>
> There's a general statement in the Errors section that passing a
> negative value for a GLsizei or GLsizeiptr is always an INVALID_VALUE
> error.  That exists in all specs back to OpenGL 1.0. :)  Since it's in a
> different place, it is often overlooked (like when we wrote these
> functions in Mesa).

Thanks a lot for pointing that out. Yeah, you're right, this is not
missing from the GLES 3.0 spec, section 2.5 says:

"
Several error generation conditions are implicit in the description of every GL
command:
<...>
* If a negative number is provided where an argument of type sizei or
sizeiptr is specified, the error INVALID_VALUE is generated.
"

So yeah, worry withdrawn!