7 Mar
2011
7 Mar
'11
2:08 p.m.
On Mar 7, 2011, at 1:21 PM, Pierre Schweitzer wrote:
Hi,
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
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? 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.