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?