On 11/20/2015 12:46 PM, Emil Velikov wrote:
> On 20 November 2015 at 20:40, Brian Paul <bri...@vmware.com> wrote:
>> ---
>> src/mesa/main/blend.c | 4 ++--
>> src/mesa/main/buffers.c | 2 +-
>> src/mesa/main/fog.c | 2 +-
>> src/mesa/main/getstring.c | 2 +-
>> src/mesa/main/points.c | 2 +-
>> src/mesa/main/texenv.c | 2 +-
>> 6 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/mesa/main/blend.c b/src/mesa/main/blend.c
>> index f07552b..2ae22e9 100644
>> --- a/src/mesa/main/blend.c
>> +++ b/src/mesa/main/blend.c
>> @@ -404,7 +404,7 @@ _mesa_BlendEquation( GLenum mode )
>> ctx->Color._BlendEquationPerBuffer = GL_FALSE;
>>
>> if (ctx->Driver.BlendEquationSeparate)
>> - (*ctx->Driver.BlendEquationSeparate)( ctx, mode, mode );
>> + ctx->Driver.BlendEquationSeparate(ctx, mode, mode);
>> }
>>
>>
>> @@ -582,7 +582,7 @@ _mesa_BlendColor( GLclampf red, GLclampf green, GLclampf
>> blue, GLclampf alpha )
>> ctx->Color.BlendColor[3] = CLAMP(tmp[3], 0.0F, 1.0F);
>>
>> if (ctx->Driver.BlendColor)
>> - (*ctx->Driver.BlendColor)(ctx, ctx->Color.BlendColor);
>> + ctx->Driver.BlendColor(ctx, ctx->Color.BlendColor);
>> }
>>
>>
>> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
>> index 93588a2..83e238a 100644
>> --- a/src/mesa/main/buffers.c
>> +++ b/src/mesa/main/buffers.c
>> @@ -731,7 +731,7 @@ _mesa_read_buffer(struct gl_context *ctx, struct
>> gl_framebuffer *fb,
>> /* Call the device driver function only if fb is the bound read buffer */
>> if (fb == ctx->ReadBuffer) {
>> if (ctx->Driver.ReadBuffer)
>> - (*ctx->Driver.ReadBuffer)(ctx, buffer);
>> + ctx->Driver.ReadBuffer(ctx, buffer);
>> }
>> }
>>
>> diff --git a/src/mesa/main/fog.c b/src/mesa/main/fog.c
>> index 45f343d..1ad939c 100644
>> --- a/src/mesa/main/fog.c
>> +++ b/src/mesa/main/fog.c
>> @@ -190,7 +190,7 @@ _mesa_Fogfv( GLenum pname, const GLfloat *params )
>> }
>>
>> if (ctx->Driver.Fogfv) {
>> - (*ctx->Driver.Fogfv)( ctx, pname, params );
>> + ctx->Driver.Fogfv( ctx, pname, params );
>> }
>>
>> return;
>> diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
>> index 06ba17c..87c5a3a 100644
>> --- a/src/mesa/main/getstring.c
>> +++ b/src/mesa/main/getstring.c
>> @@ -121,7 +121,7 @@ _mesa_GetString( GLenum name )
>> assert(ctx->Driver.GetString);
>> {
>> /* Give the driver the chance to handle this query */
>> - const GLubyte *str = (*ctx->Driver.GetString)(ctx, name);
>> + const GLubyte *str = ctx->Driver.GetString(ctx, name);
>> if (str)
>> return str;
>> }
>> diff --git a/src/mesa/main/points.c b/src/mesa/main/points.c
>> index 863e3c1..c2f2b63 100644
>> --- a/src/mesa/main/points.c
>> +++ b/src/mesa/main/points.c
>> @@ -209,7 +209,7 @@ _mesa_PointParameterfv( GLenum pname, const GLfloat
>> *params)
>> }
>>
>> if (ctx->Driver.PointParameterfv)
>> - (*ctx->Driver.PointParameterfv)(ctx, pname, params);
>> + ctx->Driver.PointParameterfv(ctx, pname, params);
>> }
>>
>>
>> diff --git a/src/mesa/main/texenv.c b/src/mesa/main/texenv.c
>> index 0919221..93c6806 100644
>> --- a/src/mesa/main/texenv.c
>> +++ b/src/mesa/main/texenv.c
>> @@ -495,7 +495,7 @@ _mesa_TexEnvfv( GLenum target, GLenum pname, const
>> GLfloat *param )
>>
>> /* Tell device driver about the new texture environment */
>> if (ctx->Driver.TexEnv) {
>> - (*ctx->Driver.TexEnv)( ctx, target, pname, param );
>> + ctx->Driver.TexEnv(ctx, target, pname, param);
>> }
>> }
>>
> Fwiw I'm all for nuking these. Any non-historical reasons why these exist ?
We used to do it like that because it was more explicit that you will
calling a function pointer. In this sort of case it's pretty obvious.
But if you see
(*foo)(param1, param2);
versus
foo(param1, param2);
the former is obviously a function pointer whereas it's not obvious
about the latter.
I think it's fine to make this change (or other
function-pointer-in-a-struct) changes, but I'd /mildly/ prefer the
explicit way for other cases... though I suspect there's a lot of
deviation from it in the codebase already.
> The is a ton in src/glx which makes the code even less pleasant (is
> that even possible) to read... in case you're bored :-P
That sounds like a job for sed.
> Reviewed-by: Emil Velikov <emil.l.veli...@gmail.com>
>
> -Emil
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
