general question..

[James Hawkins]

On Mon, Jul 21, 2008 at 9:24 PM, Chris Ahrendt <celticht32 at aol.com> wrote:
>
> Well here is my list so far :
>
> device.c - filled with goto's if you need the routines I can supply them...
> they can be moved to a routine and called...
>

wine$ find . -name "device.c"
./dlls/ddraw/device.c
./dlls/dinput/tests/device.c
./dlls/dinput/device.c
./dlls/wined3d/device.c
./dlls/d3d8/tests/device.c
./dlls/d3d8/device.c
./dlls/mountmgr.sys/device.c
./dlls/d3d9/tests/device.c
./dlls/d3d9/device.c
./programs/winedevice/device.c
./server/device.c

> context.c - same except in this case its just a return with noting else..
> why do a goto why not just do the return?
>

This is probably ok to change.  I can only imagine that the original
author thought there might be cleanup needed at some later point.

> directx.c  - same... this can be moved to a routine and simplified..
> this is in routine WineD3D_CreateFakeGLContext which I was tracing down some
> stuff...
>

cleanup usually does not warrant a new function.  This is exactly what
we use goto for.

> pixelshader.c - this has a recompile goto.. again why not make this into a
> routine?
>
> provider.c - same
>

This function is ugly, but not because it uses goto.  The function is
144 lines long, which is too long.  I'm not familiar with this code,
but I'm pretty sure some factorization is in order.  The level of
indentation could be reduced by breaking on failure instead of
proceeding on success.  Assuming this previous change is made, the use
of the goto would be that much more appealing.

>
> These are just the ones I have run accross so far..
> Why do you say that... or is the idea.. hack and get it done... one of the
> problems with goto's is it makes finding and putting in patches a pain in
> the ass.. and thats putting it bluntly..
>

Complete sentences go a long way towards effective communication :-)
The use of goto's cannot possibly be considered as a hack.  I also
don't see how you find goto's a problem when patching the code.

> Of course..  Do you have a suggestion on how I should word the RFC?
>

No, just send in a patch to wine-devel stating why you think the
change is correct.

P.S. Make sure you reply-all to cc wine-devel.  We're an open project
and we communicate openly so everyone can be a part of the discussion.

-- 
James Hawkins