[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 at 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?