[Mesa-dev] [PATCH] glsl: Assert buildin uniform variables

[Matt Turner]

On Thu, Jan 16, 2014 at 12:37 PM, Juha-Pekka Heikkilä
<juhapekka.heikkila at gmail.com> wrote:
> On Thu, Jan 16, 2014 at 8:48 PM, Matt Turner <mattst88 at gmail.com> wrote:
>> On Thu, Jan 16, 2014 at 2:59 AM, Juha-Pekka Heikkila
>> <juhapekka.heikkila at gmail.com> wrote:
>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila at gmail.com>
>>> ---
>>>  src/glsl/builtin_variables.cpp | 24 ++++++++++++++++++++----
>>>  1 file changed, 20 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
>>> index f630923..9f4f7c7 100644
>>> --- a/src/glsl/builtin_variables.cpp
>>> +++ b/src/glsl/builtin_variables.cpp
>>> @@ -669,7 +669,11 @@ void
>>>  builtin_variable_generator::generate_uniforms()
>>>  {
>>>     add_uniform(int_t, "gl_NumSamples");
>>> -   add_uniform(type("gl_DepthRangeParameters"), "gl_DepthRange");
>>> +
>>> +   const glsl_type *const depth_range_parameters_type =
>>> +      type("gl_DepthRangeParameters");
>>> +   assert(depth_range_parameters_type);
>>> +   add_uniform(depth_range_parameters_type, "gl_DepthRange");
>>>     add_uniform(array(vec4_t, VERT_ATTRIB_MAX), "gl_CurrentAttribVertMESA");
>>>     add_uniform(array(vec4_t, VARYING_SLOT_MAX), "gl_CurrentAttribFragMESA");
>>>
>>> @@ -688,7 +692,11 @@ builtin_variable_generator::generate_uniforms()
>>>        add_uniform(mat4_t, "gl_ProjectionMatrixInverseTranspose");
>>>        add_uniform(mat4_t, "gl_ModelViewProjectionMatrixInverseTranspose");
>>>        add_uniform(float_t, "gl_NormalScale");
>>> -      add_uniform(type("gl_LightModelParameters"), "gl_LightModel");
>>> +
>>> +      const glsl_type *const light_model_parameters_type =
>>> +         type("gl_LightModelParameters");
>>> +      assert(light_model_parameters_type);
>>> +      add_uniform(light_model_parameters_type, "gl_LightModel");
>>>        add_uniform(vec2_t, "gl_BumpRotMatrix0MESA");
>>>        add_uniform(vec2_t, "gl_BumpRotMatrix1MESA");
>>>        add_uniform(vec4_t, "gl_FogParamsOptimizedMESA");
>>> @@ -701,10 +709,15 @@ builtin_variable_generator::generate_uniforms()
>>>        add_uniform(mat4_array_type, "gl_TextureMatrixInverseTranspose");
>>>
>>>        add_uniform(array(vec4_t, state->Const.MaxClipPlanes), "gl_ClipPlane");
>>> -      add_uniform(type("gl_PointParameters"), "gl_Point");
>>> +
>>> +      const glsl_type *const point_parameters_type =
>>> +         type("gl_PointParameters");
>>> +      assert(point_parameters_type);
>>> +      add_uniform(point_parameters_type, "gl_Point");
>>>
>>>        const glsl_type *const material_parameters_type =
>>>          type("gl_MaterialParameters");
>>> +      assert(material_parameters_type);
>>>        add_uniform(material_parameters_type, "gl_FrontMaterial");
>>>        add_uniform(material_parameters_type, "gl_BackMaterial");
>>>
>>> @@ -714,6 +727,7 @@ builtin_variable_generator::generate_uniforms()
>>>
>>>        const glsl_type *const light_model_products_type =
>>>           type("gl_LightModelProducts");
>>> +      assert(light_model_products_type);
>>>        add_uniform(light_model_products_type, "gl_FrontLightModelProduct");
>>>        add_uniform(light_model_products_type, "gl_BackLightModelProduct");
>>>
>>> @@ -736,7 +750,9 @@ builtin_variable_generator::generate_uniforms()
>>>        add_uniform(texcoords_vec4, "gl_ObjectPlaneR");
>>>        add_uniform(texcoords_vec4, "gl_ObjectPlaneQ");
>>>
>>> -      add_uniform(type("gl_FogParameters"), "gl_Fog");
>>> +      const glsl_type *const fog_parameters_type = type("gl_FogParameters");
>>> +      assert(fog_parameters_type);
>>> +      add_uniform(fog_parameters_type, "gl_Fog");
>>>     }
>>>  }
>>>
>>> --
>>> 1.8.1.2
>>
>> Does this help something? asserts are no-ops in optimized builds, so
>> adding them won't fix klocwork issues.
>
> I did not think checking these build in types outside debug builds
> would make much sense thus only assert. I can of course change them to
> normal if(null) checks but I was thinking if these ever fail outside
> development work there is something very wrong.

I agree -- if these fail something is terribly wrong. Since they're
hardcoded built-in variables I think there's zero chance that they'll
fail, so I'd ignore this klocwork issue.