Re: Reentrancy issue
On Thu, 31 Jan 2008 18:59:32 GMT, "David Ching" <dc@remove-this.dcsoft.com>
wrote:
"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.
Yawn.
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.
So you've said. The burden is on you to express yourself clearly and
unambiguously, and when you feel you need to clarify yourself, do that
clearly and unambiguously. I'd be at least a little sympathetic to what
you're accusing me of now if you could show me where I've taken you out of
context or otherwise replied unfairly to something you said, which by all
appearances, stood on its own. My posts certainly stand on their own, and
you respond to them by saying things I can't agree with, and when I explain
why, you like to claim you've said things elsewhere, which if true, are
different than what you told me directly and are currently arguing about.
I've commented on this once already in this thread, and in hopes that you
can see where the problem really is, I'll repeat it:
<q>
And elsewhere, Joe admitted that BOOL does equal 1 or 0 on Windows NT API's
Did he? When the documentation says "returns non-zero", no one can say
that. It's not "his to admit", and I'm not aware that he "admitted"
anything like that anyway.
so it is not a problem with these, as I clearly said. That was what I was
referring to by "Windows Programming" although I said there might be
problems with other libraries.
I guess I didn't see that. You've been talking to me about "real life", and
when I mentioned Windows "for example", you latched on to that and replied:
<q>
It's wrong but since Windows API's do actually return 1 for TRUE (at least
all that I've seen), it does not cause an error in real life.
</q>
I don't know what you think you "clearly said", but that's what you
*actually* said. To me, anyway.
</q>
Joe has denied what you claimed he "admitted", and indeed, as I suspected,
he didn't "admit" what you said he did. You did not refer to "Windows NT"
APIs, despite what you think you "clearly said". And you did not refer to
"other libraries" in your posts to me. It's really unbelievable that
instead of proving what you think you said, or just plain saying what you
mean, you again are trying to place the blame on me for not reading the
rest of what you think you wrote in these interminable threads I frequently
observe you in.
Reading it once again, I'm amused to see you held Joe up as an authority on
the Windows NT API when it suited your purposes, when the rest of your
considerable energy is being spent trying to prove he's an unreliable
hypocrite whose personal experience should not be trusted, unlike you, with
your "real life". I really do feel like I'm in a maze of twisty passages,
all alike, and I'm about to call for helicopter rescue.
The point is that Windows documentation contains gray areas.
Yes, I know. I've been dealing with, commenting on, and trying to get at
least some of those "gray areas" fixed for about 15 years.
#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.
That might be relevant if I had criticized it, much less mounted my "high
horse". Provided the data is treated as read-only, and the other rules
pertaining to the lifetime of the returned pointer are observed, it's a
non-issue. Do you *really* want to talk about this?
#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."
The documentation does not "imply" non-zero; it states it unequivocally.
You have no valid way to contradict it, while it is possible to contradict
the documentation for the CString issue for x86 VC4-VC9; I'm not going to
further rehash what I've already written about in depth. Finally, your
CreateProcess/other API claim assumes still more facts not in evidence:
1. There are enough "terribly naive" (sorry, couldn't resist) people
writing == TRUE over enough APIs to have encountered problems due to it.
2. That they've publicized it instead of fixing it and silently moving on.
3. That we would've heard about their publicizing it.
4. That Joe and Tom don't know what they're talking about.
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.
Premise-wise, #1 is nothing like #2 and #3, and #2 and #3 are different.
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.
OK, but again, I don't care that you think someone's a hypocrite or what
you think the thread "is about".
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.
But the truth is, #1 is nothing like #2 and #3, and #2 and #3 are
different.
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
I have no idea what "previous thread" you're talking about. I expect any
unhelpfulness you perceived is due to the same traits you've exhibited in
this thread. Concerning this thread, what was it about this excerpt from my
first reply to you that you found unclear?
<q>
BOOL b;
if ( b == TRUE) // Wrong; do not imitate.
</q>
Even if you consider the documentation "gray", which has been explained ad
infinitum it is not in this area, what don't you get about "Wrong; do not
imitate?" What don't you get about my explanation for why it should not be
imitated?
or about how to treat colleages who choose to interpret them
differently than you do.
"How to treat colleagues" is your hobby horse of the moment. It's not
relevant to the discussion I've been trying to have with you.
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".
No, you deny the risk, compare it to the wrong things, and argue endlessly
when someone states what you are now laughably trying to characterize as
"obvious".
I mean, without qualifying how much
risk you're in, that doesn't tell you anything about the quality of your
app.
I explained to you that the BOOL risk involves unknowns and the CString
risk does not, at least for x86 VC4-9. I can't determine the risk any
better than that, except to note that Joe and Tom have mentioned being
bitten by the BOOL thing.
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.
Why are you still arguing about this? The whole point of applying "best
practices" is to minimize your exposure to problems. Preferring "if (b)"
eliminates the non-zero risk that comes with "if (b == TRUE)," and it is a
"best practice" that has been recognized for decades. There is *no*
advantage to saying "if (b == TRUE)". These are the sorts of things *I*
think people should be focusing on, not your interminable arguing about
silliness such as "relative naivet9" and whether or not someone's a
hypocrite, which you have just tried to establish at even greater length
than before. I told you before, I'm not interested in that. At all.
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.
Yawn.
--
Doug Harrison
Visual C++ MVP