[Mesa-dev] [PATCH] mesa: replace GLenum with GLenum16 in common structures

[Marek Olšák]

>>   struct gl_colorbuffer_attrib
>>   {
>>      GLuint ClearIndex;                      /**< Index for glClear */
>>      union gl_color_union ClearColor;        /**< Color for glClear,
>> unclamped */
>>      GLuint IndexMask;                       /**< Color index write mask
>> */
>>      GLubyte ColorMask[MAX_DRAW_BUFFERS][4]; /**< Each flag is 0xff or 0x0
>> */
>>
>> -   GLenum DrawBuffer[MAX_DRAW_BUFFERS];        /**< Which buffer to draw
>> into */
>> +   GLenum DrawBuffer[MAX_DRAW_BUFFERS];    /**< Which buffer to draw into
>> */
>
>
> GLenum16 ?

We pass "buffers" from glDrawBuffers and ctx->DrawBuffer to
_mesa_drawbuffers, so there is a type conflict.


>> diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
>> index 8a4b659..3fad4c7 100644
>> --- a/src/mesa/vbo/vbo_save_draw.c
>> +++ b/src/mesa/vbo/vbo_save_draw.c
>> @@ -133,21 +133,21 @@ _playback_copy_to_current(struct gl_context *ctx,
>>   static void vbo_bind_vertex_list(struct gl_context *ctx,
>>                                    const struct vbo_save_vertex_list
>> *node)
>>   {
>>      struct vbo_context *vbo = vbo_context(ctx);
>>      struct vbo_save_context *save = &vbo->save;
>>      struct gl_vertex_array *arrays = save->arrays;
>>      GLuint buffer_offset = node->buffer_offset;
>>      const GLuint *map;
>>      GLuint attr;
>>      GLubyte node_attrsz[VBO_ATTRIB_MAX];  /* copy of node->attrsz[] */
>> -   GLenum node_attrtype[VBO_ATTRIB_MAX];  /* copy of node->attrtype[] */
>> +   GLenum16 node_attrtype[VBO_ATTRIB_MAX];  /* copy of node->attrtype[]
>> */
>>      GLbitfield64 varying_inputs = 0x0;
>>
>>      memcpy(node_attrsz, node->attrsz, sizeof(node->attrsz));
>>      memcpy(node_attrtype, node->attrtype, sizeof(node->attrtype));
>>
>>      /* Install the default (ie Current) attributes first, then overlay
>>       * all active ones.
>>       */
>>      switch (get_program_mode(ctx)) {
>>      case VP_NONE:
>>
>
> Did you find this memcpy() issue by inspection or debugging?  Off-hand I
> don't know if there's other instances to deal with.  It's something we'll
> have to be mindful of.

Debugging. I also inspected other memcpy uses. It looks like this is
the only one copying an array of GLenum.

Marek