[Mesa-dev] Mesa (master): tnl: Initialize gl_program_machine memory in run_vp.

[Keith Whitwell]

On Mon, 2010-12-13 at 07:09 -0800, Brian Paul wrote:
> On 12/10/2010 03:27 PM, Vinson Lee wrote:
> > Module: Mesa
> > Branch: master
> > Commit: ef3f7e61b314236cbb7ed2cf24d34c6f90d9cfca
> > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=ef3f7e61b314236cbb7ed2cf24d34c6f90d9cfca
> >
> > Author: Vinson Lee<vlee at vmware.com>
> > Date:   Fri Dec 10 14:24:05 2010 -0800
> >
> > tnl: Initialize gl_program_machine memory in run_vp.
> >
> > Fixes piglit valgrind glsl-array-bounds-04 failure (FDO bug 29946).
> >
> > NOTE:
> > This is a candidate for the 7.10 branch.
> > This is a candidate for the 7.9 branch.
> >
> > ---
> >
> >   src/mesa/tnl/t_vb_program.c |    2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/mesa/tnl/t_vb_program.c b/src/mesa/tnl/t_vb_program.c
> > index 76f8fde..7e7c59a 100644
> > --- a/src/mesa/tnl/t_vb_program.c
> > +++ b/src/mesa/tnl/t_vb_program.c
> > @@ -311,7 +311,7 @@ run_vp( struct gl_context *ctx, struct tnl_pipeline_stage *stage )
> >      struct vp_stage_data *store = VP_STAGE_DATA(stage);
> >      struct vertex_buffer *VB =&tnl->vb;
> >      struct gl_vertex_program *program = ctx->VertexProgram._Current;
> > -   struct gl_program_machine machine;
> > +   struct gl_program_machine machine = { 0 };
> >      GLuint outputs[VERT_RESULT_MAX], numOutputs;
> >      GLuint i, j;
> 
> I think there's a better fix.  The above will initialize the whole 
> object to zeros for every function call (and be a performance hit).  I 
> think we really only need to do it once to avoid the valgrind warning.
> 
> I've got a new patch that I'll commit.

Also, this idiom of partially initializing structures with {0} seems to
cause gcc to squawk about all the fields which weren't included in the
initializer.

MSVC apparently doesn't complain, and it is a convenient idiom providing
the compiler likes it.

On balance, I like getting those warnings from gcc as they can spot real
bugs elsewhere, so I'd prefer not to have code which causes us to want
to turn the warning off...

Keith