Re: [ros-dev] Re: [ros-svn] [gdalsnes] 18113: -reorder InsertXscendingOrder macro argument order and update uses

[Gregor Anich]

On Tuesday 27 September 2005 01:14, Alex Ionescu wrote:
>   gdalsnes(a)svn.reactos.com wrote:
> >  -reorder InsertXscendingOrder macro argument order
> > and update uses
> > -start to macrofy list enums in ntoskrnl using LIST_FOR_EACH macros
> > -use IsListEmpty some places instead of manual coding
> > -profile.c:KeStartProfile() zero correct buffer in (and not the NULL
> >  ptr;-) -improve LIST_FOR_EACH macros so that the iterator is set to NULL
> >  at end of enum -kthread.c:KiServiceCheck() set the shadowtable before
> >  calling the win32k proc/thread init funcs -apc.c:KiInsertQueueApc()
> >  insert special apcs in correct fifo order -apc.c:KeFlushQueueApc()
> >  simplify
> > -timer.c:KiExpireTimers() calling RemoveEntryList on a possibly empty list
> >  is not ok
> >
> >
> > Updated files:
> > trunk/reactos/include/reactos/helper.h
> > trunk/reactos/ntoskrnl/io/device.c
> > trunk/reactos/ntoskrnl/io/driver.c
> > trunk/reactos/ntoskrnl/io/file.c
> > trunk/reactos/ntoskrnl/io/fs.c
> > trunk/reactos/ntoskrnl/io/irp.c
> > trunk/reactos/ntoskrnl/io/pnpnotify.c
> > trunk/reactos/ntoskrnl/io/pnproot.c
> > trunk/reactos/ntoskrnl/ke/apc.c
> > trunk/reactos/ntoskrnl/ke/bug.c
> > trunk/reactos/ntoskrnl/ke/kqueue.c
> > trunk/reactos/ntoskrnl/ke/kthread.c
> > trunk/reactos/ntoskrnl/ke/profile.c
> > trunk/reactos/ntoskrnl/ke/queue.c
> > trunk/reactos/ntoskrnl/ke/timer.c
> > trunk/reactos/subsys/system/usetup/partlist.c
> > trunk/reactos/subsys/win32k/ntuser/class.c
> >
> > __________________________ 
>  Hi,
>
>  I'm going to have to voice my extreme outcry against this patch. It is
>  replacing clear and easily debuggable code by non-standard macros which
>  are impossible to debug. It is also going to create problems when people
>  which are not used to them (such as myself):
>
>  1) Have no idea what some LIST_FOR_EACH_SAFE thing is doing vs
>  LIST_FOR_EACH vs InsertListLifoSafeMaybeLoopOrWhoKnowsWhat
>  2) Will never code using these macros, and thus the source will become
>  full of both methods, which is totally ugly.
>
>  Sometimes, especially in kernel code, it's much better to have an
>  expanded logic then to use a macro. I wrote a great majority of the code
>  that has just been, imho, pollutted with these macros, and I don't
>  appreciate for someone to barge in and change my code for some macro
>  that I don't understand, nor wish to, because it only causes problems. I
>  take great care of the code I write and "own" it (in the programming
>  term) so that if a bug in it arises, I can quickly identify it and be
>  held responsible for it. The addition of these macros hinders that effort.
>
>  I don't mind someone using them inside his or her own code. I just mind
>  their usage in ntoskrnl, and even more so when it overwrites the clean,
>  clear code that I've written and am used to debugging.
>
>  Best regards,
>  Alex Ionescu 

You know, it also sucked when you changed the syntax of all the assembly files 
in ntoskrnl, thats when i stopped working on it. So, are you the only one who 
is allowed to do such changes because you believe to be the best?