Re: Reentrancy issue
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:u1a1q3l1g8faf022tt6v5cb56miabjmvg2@4ax.com...
My bad. In this thread, you're simultaneously holding the position that
the
documentation trumps "real life" for one thing and that "real life" trumps
the documentation for the other, so I didn't have to refer to "past
discussions" at all. Please excuse this lapse, but also understand I was
genuinely shocked to read your "disregard any effort" statement, as I
remember how you've dismissed inconvenient documentation in past
discussions. I also found it highly ironic since you've repeatedly accused
Joe of "hypocrisy" in this thread.
That's where I was coming from. I'd leave it at that, but your "backhanded
slaps" accusation followed immediately by your claim to the "high road"
further reminds me of a past discussion in which you dismissed true things
I and others said that are defined by the language standard, no less, as
"ludicrous" (hence my amusement at you now holding MS documentation up as
gospel), that I "miss the forest for the trees", that "we have different
goals and values for our lives", and so-snidely-forth.
You still are missing the forest from the trees. And I would not be talking
about snideness if I were you. Pot. Kettle. Black.
Part of this is caused by your not reading all posts in a thread that you
jump into. So you miss relevant things that I say. The point is that
Windows documentation contains gray areas.
#1: Many Windows API's do not prototype const when in fact the parameter is
treated as const. That's why in real life it is safe to cast, e.g. LPBYTE
to LCBYTE (or CString to (LPCTSTR) via (LPTSTR) instead of using GetBuffer).
Nevertheless, you can get on your high horse and criticize those who do this
because it technically does not follow the documentation.
#2: Another gray area is passing CString as a variable parameter without
explicitly casting it to (LPCTSTR). Until someone shows actual
documentation, I treat this as undocumented. Several "eye witnesses" report
they've seen it, but that's not proof. I have some old MSDN libraries from
the mid-90's and if I have some time it would be interesting to install them
and see if this documentation really does exist. But whether it was there
or not, the fact is that current documentation does say "don't do it" even
though we know that it is not a problem in real life. FWIW, I think Joe is
doing the right thing by explicitly casting from now on. Whether or not it
was naive to do so in the past we can agree to disagree. I think it was
naive, and in fact, I did it myself for a time, so I was naive then too. If
for no other reason that it established a habit of not explicitly casting
variable parameters, and you got in trouble when passing other types besides
CString.
#3: Another gray area is treating non-zero BOOL == TRUE. The documentation
implies not to assume that. But like the preceding paragraph, real life
tells it is currently safe, at least on Win NT. If it were not, we would
have heard "this is not true for CreateProcess(), or whatever the offending
API is."
As I said before, and I will repeat it here for your benefit since I
apparently can't assume you've taken the time to read all the posts in the
thread: none of the above 3 things are major sins in that they are not
likely to cause problems, but it is best practice to follow the
documentation. And in fact I do clean up the code that I am currently
modifying to more closely follow the documentation.
Behavior-wise, the hypocrisy comes into play when someone takes liberties in
any of the above gray areas (and I'm sure there are more) while lamblasting
someone for taking liberties in different area. That was my point to Joe.
The rest of this sub-thread disolves into what is naive and what isn't, and
people trying to save face by twisting the logic to make them non-naive.
But the forest is: if you do any of the above 3 things, the world won't
stop turning, but try to make it better.
And there's that ugly word "hypocrisy" again. You know, I don't care if
you
think someone's a hypocrite, and if that's what "ties things together" for
you, then I really am wasting my time. Here I've been going into great
detail on the technical aspects of what you've been saying, and your
motivation is proving "hypocrisy" concerning "relative naivet9". Thanks
for
clarifying that.
You're welcome. As in the previous thread, your technical aspects don't
help much in deciding what to do about the gray areas of Windows
documentation, or about how to treat colleages who choose to interpret them
differently than you do.
Who's twisting whose words? I don't know from where you pulled this
statement "recommending of dropping everything and combing the codebase
for
BOOL comparisons with the zeal you would eliminate buffer overruns." I
haven't recommended doing anything about it. My statement above about
"risk" was factual and descriptive and should be understood in the context
in which I said it, which to sum it up, was, "If you don't fix CString
now,
you're not at risk, because it provably works on existing systems, while
if
you don't fix the BOOL thing now, you are at risk, because unknowns are in
play on existing systems." If I had intended to be prescriptive, I would
have said something very different. Maybe the problem is that you perceive
some difference between "LEVEL of risk" and just plain old "at risk", such
that you think the latter implies certainty. It does not. Anyway, pardon
me
for speculating why you say things like this, but it really does puzzle
me.
Remember when I said we have different life goals? This is why I said that.
I really am all about being "prescriptive" and sharing how I approach
programming on a daily basis. I don't engage in discussion about stating
the obvious that "you are at risk". I mean, without qualifying how much
risk you're in, that doesn't tell you anything about the quality of your
app. All apps ship with known bugs that put them "at risk" but that says
nothing about whether they will be successful or not. And that's what I
think people should be focusing on. So that's my life goal, and I'm
pursuing it. Don't expect me to applaud you for pursuing a different life
goal that I don't share.
-- David