On Mar 7, 2011, at 1:21 PM, Pierre Schweitzer wrote:
Hi,
this commits just shows you didn't understand how that function works. If you had, you wouldn't have said: "- Implement parameters checking in FsRtlIsNameInExpressionPrivate." It's already done.
Enlighten me please, where? Is it crypted in the last return statement? If so, how many of you would decipher, it should return TRUE if both Name and Expression are empty, and false if any of them is not empty? And how many of you would break this in an attempt to improve the algorithm and thus break that nice 119 chars return statement?
And we may wonder why you upcase expression in your test, whereas you're not supposed to do so, and you even asserted it was not needed.
Thanks, that upcasing was really unnecessary, I committed a fix in 50992.
This answer confirms you didn't understand the algorithm. So, let's throw some light on it. Line 100, line 160, line 163, line 165, line 166, line 204.
Common practice for any (kernel) function really (if you look at all other APIs in Ob, Ex, Ke, etc) is to: 1. Check parameters for validity and return if they are invalid or if no work of an algorithm is required. 2. Do the work 3. Return result of calculations and status.
Sometimes, step 2. is divided into two substeps: 2.1. Check for simple cases and return right away. This may be seen as optimisation or simplifying. 2.2. Factoring out complex parts of an algorithm to subblocks of code (prepare some data, process it, compare and calculate results).
Or sometimes, if there is a complex algorithm, a common approach is to divide the generic algorithm into two parts: a. First part deals with simple cases and provides result right away b. Second part deals with complex cases.
Why is it done so? They should have taught you this in the higher school, but I will explain. If you put a+b into one algo, it'll be more complex by definition. If you're able to decompose the original problem into a set of smaller sub-problems, you win: simplicity, maintainability and easier development/testing.
I'm deeply sorry, I'm not a genius. When first designing the algorithm, I didn't took into account all the possible cases. And when new cases were
That's what I'm talking about. You were so much frustrated that I dared to touch your code, that I got an impression that you are genius really, and consider all your code as being perfectly perfect.
For pool overruns issue, that's the poorest excuse I've ever seen. In my commit message there were several lines. Surely one reads: "This fixes potential buffer overruns.". Yeah, great, I coded poor algorithm you won!
I didn't really questioned authorship of the algorithm. If an algorithm contains errors, I don't really care who wrote it, I would just go and fix it.
And with a so excellent résumé, I would advice you switch to PnP.
Thanks for the advice, I have a full queue of such advices, but time is not infinite, so I have to put some priorities.
Which bug? Any link where to read bout that bug? Any serious proof?
First hit in google: http://www.osronline.com/showThread.CFM?link=180514
Now given all the information, I kindly ask you to revert both r50981 & r50982.
Sorry, request very politely rejected.
Because yes, that algorithm still has issues, but we're not likely to hit them before a while.
Yeah that's why I wanted to remove complexity from the underlying algorithm and factor out two simplest and the most common queries into standalone code path. Now it's easier to improve that algorithm to deal with more complex scenarios.
P.S. Why do you really sound so much offended by those codelines? They have nothing against you, neither about possible problems, it's not really your fault. I do mistakes too and what? It's much better to learn on mistakes than try to argue about them.
Anyway, it's not a productive way at all. If we start arguing about personal offences, then ReactOS would remain a toy project forever. It's time to get serious and put away all your personal frustration, internal issues and the like.
WBR, Aleksey.