Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OES_viewport_array: Missing INVALID_RANGE error from ScissorArrayvOES() #79

Open
jamieTaylorIMG opened this issue Jul 21, 2017 · 4 comments

Comments

@jamieTaylorIMG
Copy link

The function ScissorArrayvOES() added by OES_viewport_array is missing this entry in its error section/listing:

"An INVALID_VALUE error is generated if is negative."

This should probably be added to make it consistent with ViewportArrayvOES() and DepthRangeArrayfvOES(). Also, this error message as used to describe ViewportArrayvOES() has an unnecessary '>' character at the end.

@ghost
Copy link

ghost commented Oct 25, 2017

It's been noted that in section 2.3 - Command Execution (OpenGL ES 3.2 Specification), there is a general error called out for all negative values provided to sizei parameters:

If a negative number is provided where an argument of type sizei or
sizeiptr is specified, an INVALID_VALUE error is generated.

So technically the error is there, it's just not called out. We're raising a bug internally to try to resolve this inconsistency.

@ghost ghost assigned pdaniell-nv Oct 25, 2017
@pdaniell-nv
Copy link
Contributor

The internal issue is https://gitlab.khronos.org/opengl/API/issues/52

@pdaniell-nv pdaniell-nv assigned oddhack and unassigned pdaniell-nv Oct 31, 2017
@oddhack
Copy link
Contributor

oddhack commented Apr 17, 2019

Although it took a while, we did address the missing sizei < 0 error (which was quite widespread) in the core specs. While it would be nice to eventually do this in the separate extension documents, it's a huge amount of tedious work of limited benefit; if you were to propose a PR matching the error in the GL 4.6 spec in this specific case (or as many cases in different extensions as you had energy for), we are open to it, otherwise it isn't going to happen anytime soon.

@oddhack
Copy link
Contributor

oddhack commented May 13, 2019

Assigning this back to @jamieTaylorIMG as I'm not planning to do it for extensions, unless the WG specifically tasks me with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
@oddhack @pdaniell-nv @jamieTaylorIMG and others