[Mesa-dev] [PATCH 01/14] mesa: add bind_transform_feedback() helper

[Samuel Pitoiset]

On 08/24/2017 03:58 PM, Ilia Mirkin wrote:
> On Thu, Aug 24, 2017 at 9:57 AM, Samuel Pitoiset
> <samuel.pitoiset at gmail.com> wrote:
>>
>>
>> On 08/24/2017 03:24 PM, Ilia Mirkin wrote:
>>>
>>> On Thu, Aug 24, 2017 at 9:21 AM, Samuel Pitoiset
>>> <samuel.pitoiset at gmail.com> wrote:
>>>>
>>>> Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
>>>> ---
>>>>    src/mesa/main/transformfeedback.c | 28 ++++++++++++++++++----------
>>>>    1 file changed, 18 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/src/mesa/main/transformfeedback.c
>>>> b/src/mesa/main/transformfeedback.c
>>>> index a075d0875a..d61db4eb62 100644
>>>> --- a/src/mesa/main/transformfeedback.c
>>>> +++ b/src/mesa/main/transformfeedback.c
>>>> @@ -1062,10 +1062,26 @@ _mesa_IsTransformFeedback(GLuint name)
>>>>     * Bind the given transform feedback object.
>>>>     * Part of GL_ARB_transform_feedback2.
>>>>     */
>>>> +static ALWAYS_INLINE void
>>>> +bind_transform_feedback(struct gl_context *ctx, GLuint name, bool
>>>> no_error)
>>>> +{
>>>> +   struct gl_transform_feedback_object *obj;
>>>> +
>>>> +   obj = _mesa_lookup_transform_feedback_object(ctx, name);
>>>> +   if (!no_error && !obj) {
>>>> +      _mesa_error(ctx, GL_INVALID_OPERATION,
>>>> +                  "glBindTransformFeedback(name=%u)", name);
>>>> +      return;
>>>> +   }
>>>> +
>>>> +
>>>> reference_transform_feedback_object(&ctx->TransformFeedback.CurrentObject,
>>>> +                                       obj);
>>>
>>>
>>> Is the CurrentObject allowed to be null (which it could be in the
>>> no-error case)?
>>
>>
>> I assume in the no-error case, obj shouldn't be NULL, otherwise it might
>> crash (later on) and I think it's expected.
> 
> Really? I didn't realize that crashing was allowed...
> 
> """
>      If this context was created with the no error mode enabled then any place
>      where the driver would have generated an error instead has undefined
>      behavior.  This could include application termination.  All calls to
> """
> 
> OK, yeah.

Yeah, applications that will enable KHR_no_error really need to be 
error-free. :)

>