Re: Reentrancy issue
"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.
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,
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.
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.
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.
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. 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. 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? But
saying if (b == TRUE) 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.
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....
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>
(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, 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.
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. 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.
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.
-- David