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

[Alex Ionescu]

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