Re: Reentrancy issue
On Tue, 29 Jan 2008 13:47:52 -0800, "David Ching"
<dc@remove-this.dcsoft.com> wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:kklup31o41h7dnq5h11j1vjc7ign3qasuh@4ax.com...
On Sun, 27 Jan 2008 13:10:19 -0800, "David Ching"
<dc@remove-this.dcsoft.com> wrote:
I disregard any effort MS may or may not have done for making the CString
cast unnecessary. Obviously they do not stand behind that effort, as per
the article cited by Giovanni.
Hmmm, that would seem to obligate you to respect all documentation, yet
from past discussions, I know you don't. For all your talk of "real life",
in the past, you've rejected rules that matter, and now, you're honoring
one that doesn't. Just an observation. :)
Man, where are you coming from? The only cited documentation on the subject
was the one by Giovanni. You and Joe have yet to produce any documentation
that the CString hack was guaranteed to work. Since I'm used to your
backhanded slaps, I'll not even dignify the rest of this.
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.
I agree that not casting the CString is not currently a problem, but
improper comparison of a BOOL could currently cause problems.
OK!
However, I've not seen this in real life.
Oh. I understand you haven't seen this. You said that last time. What you
mean is, "So far, I've not observed a problem with the BOOL thing in my
own
Windows programming." See my last message to understand why your "real
life" experience represents but a tiny sample of reality, and note also
that at least two people in this thread have said they've had problems
with
the BOOL thing.
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.
You ignore my point that no evidence was offered that removing the
comparison directly fixed known bugs; rather everyone discussed rather
anecdotal, "I went through a code base and removed all the comparisons, and
some bugs didn't occur anymore." For such a rigorous guy, I'm surprised you
let that one pass. I believe these really did fix some problems using some
3rd party API's, but it was not proven by any means.
Given that the documentation for the Windows API uses the phrase "returns
non-zero", not "returns TRUE", and that it's impossible to prove that it
means the latter, what they said is plausible even for Windows, not just
these "3rd party APIs" you're talking about now. I have no basis to
challenge them. This follows logically from what I posted a couple of
messages ago. I think the real reason you find "it surprising I let it
pass" is because you have such a stake in finding them wrong, and it's
impairing your comprehension.
So the bottom line for me is: I think it is
splitting hairs about which is more likely to cause a problem in real
life.
One is clearly more likely to cause problems in "real life". That's what I
established in my last message, and Joe and Tom have confirmed it in their
own "real lives". I don't get why you've been trying to equate the BOOL
thing with the CString issue throughout this thread. The two aren't
related
at all, and the result of saying they're equivalent is a number of people
explaining to you that they're not. Now you're characterizing this as
"splitting hairs". Round and round it goes!
They are tied together by the hypocrisy that I (at least) see by Joe's
insistance that one is OK but not the other.
FWIW, I see that Joe replied to you 4 days before you wrote that:
<q>
Because of the change in the specification of the CString class, I will be
changing to use the explicit cast.
</q>
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.
The bottom line is if they are causing a problem, they need to be fixed,
otherwise, making them optimal can wait until it is convenient to cleanup
the code.
"Don't fix what ain't broke." The problem is determining what's "broke"
and
what isn't,
I agree.
and as I explained last time, and Joe and Tom added in their
own messages, you can't make a reliable determination of that for the BOOL
thing. You can for the CString issue. If you don't fix the BOOL thing now,
you are at risk in "real life", which is far bigger than your own personal
experience.
You twist my words.
How so?
The LEVEL of risk in real life is more than the CString
thing (which as you said is currently 0), I admit, but not what you guys are
recommending of dropping everything and combing the codebase for BOOL
comparisons with the zeal you would eliminate buffer overruns.
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.
Buffer overruns - now if you wanted to call those "naive" I would agree with you.
How stupid can you be not verifying you have enough memory allocated?
You could come up with a gazillion other comparisons like this, but they
illuminate nothing, and again, I find it unproductive to argue with you
endlessly about "relative naivet9". Maybe you'd find it amusing to create a
"taxonomy of naivet9" or something. :)
But saying if (b == TRUE)
[edit: is naive]
when it is totally fine if libraries are sanely
implemented, and is so engrained in other languages is just putting your
colleages down for no reason.
For C and C++ programming, it's typically not "totally fine", and the
Windows API says it's not "totally fine". As for it being "engrained in
other languages", I guess I haven't encountered them, or at least used them
in a long time, because none come to mind. It's generally not nice to "put
people down", in fact it's usually counter-productive, but I really hope
you realize that whether or not you approve of Joe's use of the word
"naive", he was giving good advice WRT the BOOL thing.
Since it is splitting hairs, it remains hypocrtical to call one
naive while blissfully practicing the other.
Although it completes your (false) syllogism, no one's suggested
"blissfully practicing the other".
For not "blissfully practicing it" Joe was pretty proud of the number of
years he had used it....
I didn't realize you were talking about Joe in your replies to me; you
hadn't mentioned him to me until this message. FWIW, I see Joe replied to
you 4 days before you wrote the above:
<q>
Because of the change in the specification of the CString class, I will be
changing to use the explicit cast.
</q>
Remember, you're talking to the guy who
filed a feedback item on the ellipsis issue a couple of years ago, which
if
implemented, would "penalize" everyone relying on the CString hack with a
warning (assuming MS didn't go to still more heroics to suppress the
warning for CString as I described in my reply to Giovanni):
Compiler should warn about passing objects of non-POD types to the
ellipsis
Opened 6/13/2005
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98899
<q>
Proposed Solution
VC++ should warn about passing objects of non-POD class types to the
ellipsis. While MFC's CString may have been designed to permit this, the
current documentation frowns on the practice:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Strings3a_CString_Operations_Relating_to_C2dStyle_Strings.asp?frame=true
"it is essential that you use an explicit type cast when passing a CString
object to a function that takes a variable number of arguments."
Thus, implementing this warning will reinforce the MFC documentation in
addition to helping all the non-CString cases.
</q>
Of course, my real concern was for types for which it actually matters
(i.e. "real life"), such as std::string; I was surprised and amused to
find
the CString documentation and included it more for "shock value" than
anything, since it didn't apply to x86 at least and contradicted
longstanding common practice. To this day, it doesn't apply to x86. I've
been careful all along to qualify this by saying "x86", because for all I
know, the 64-bit compiler may do things differently, and if so, the
CString
hack might not work. In that case, the documentation would apply, and it
would make implementation of the warning that much more desirable.
I don't know if you mean only std::string applies in real life, and not
CString
No, I meant that std::string is actually subject to the problem. I gave an
example of this in the feedback item. Above, I explained why I included the
CString documentation in the feedback item, and elsewhere in this thread,
I've explained why x86 CString isn't subject to the problem.
but regardless I think your warning suggestion was a good one. But
I don't know why you bring this up again, I never said anything about your
Feedback Item.
When you tell me I'm "splitting hairs" for disagreeing with you, and for
all appearances (you hadn't spoken about Joe at that point), that I'm
suggesting "blissfully practicing" something, and you refer to Giovanni
quoting some documentation in this thread, I thought it relevant to show
you that I was thinking about this issue years ago and quoted the same
documentation when I finally became motivated enough to create a feedback
item for it over 2.5 years ago, whose implementation would discourage the
practice. Mentioning it also allowed me to expand even further on what I
think of as "real life" concerns.
As for the "relative naivet9" of the two things, which you are talking
about once again, FWIW, the BOOL thing is *by far* the more naive of the
two. It has an *ancient* history, and you know what? I could pass a
CString
or std::string to the ellipsis not because I'm "naive", but because I made
a mistake, which is what motivated me to create my feedback item. But I
could never write (b == TRUE) by mistake; I could write it only if I
didn't
know better and thus were "naive", to put it in the terms you've been
using.
"Naive" was a word used by Joe. And his usage of not casting CString was
not a mistake, he was taking advantage of a known (and invalid, now, and for
lack of documentation, always) hack.
It provably works for x86, at least, now and for the last 10 years at
least, so I can't quite bring myself to call it "invalid". And again, I
don't care what Joe was doing. What I said stands on its own.
This hack prevents deriving from
CString. I'm not sure if it's the only reason, but this is not a good
thing. It is indeed naive, whether his usage of it is in the same context
as yours or not.
If you mean the hack constrains the design of CString in certain ways that
make it a poor candidate for public derivation, I don't see it as a big
loss. Fundamental string classes should be minimal. The "non-naive" way to
extend the CString interface is through non-member functions, while the
traits mechanism can be used to create string types that behave differently
WRT things like comparison policy.
My post discussing whether the BOOL comparison is in bad style or is
incorrect pretty much sums up my opinion and I won't be spending any more
time on this topic.
OK.
--
Doug Harrison
Visual C++ MVP