Bad pointer on CString
in [Visual C]
|
From: Scot T Brennecke on 22 Sep 2009 03:29 David Webber wrote: > > "Alexh" <alexh1(a)sbcglobal.net> wrote in message > news:7fb562ec-a3fe-4faf-8c76-87716709201b(a)f20g2000prn.googlegroups.com... > >> class Myclass : public CObject >> { >> >> CString MyCstring; >> >> ... >> >> The debugger reports that the CString has a bad pointer (all 0's). > > *When* is it reporting it? > > It isn't at all clear to me that the internal pointer of a CString > cannot legally be NULL. I've always thought it could be, and that the > CString methods allowed for it. > > I can't remember if I ever checked, but even if I did, it may be > different in different implementations. But I have always allowed for > the possibility that the standard cast > > (LPCTSTR)my_cstring; > > might return NULL. If it can, and you assume it doesn't, then you > might run into trouble. But (if I'm right) I can't think where else > the debugger might report a problem? > > Dave Nope. Check out the code for the ATL::CStringT (really the ATL::CSimpleStringT) class templates. You'll see that the m_pszData member should never be NULL. The (LPCTSTR) cast returns the m_pszData as a string pointer, but it's also expected to be a valid address that can be manipulated to get to the CStringData object for that string.
From: David Webber on 22 Sep 2009 18:30 "Scot T Brennecke" <ScotB(a)Spamhater.MVPs.org> wrote in message news:uFh2%23Z1OKHA.4580(a)TK2MSFTNGP06.phx.gbl... > David Webber wrote: >> >> It isn't at all clear to me that the internal pointer of a CString cannot >> legally be NULL. I've always thought it could be, and that the CString >> methods allowed for it. >> >> I can't remember if I ever checked, but even if I did, it may be >> different in different implementations. But I have always allowed for >> the possibility that the standard cast >> >> (LPCTSTR)my_cstring; >> >> might return NULL. If it can, and you assume it doesn't, then you might >> run into trouble. But (if I'm right) I can't think where else the >> debugger might report a problem? >> >> Dave > > Nope. Check out the code for the ATL::CStringT (really the > ATL::CSimpleStringT) class templates. You'll see that the m_pszData > member should never be NULL. The (LPCTSTR) cast returns the m_pszData as > a string pointer, but it's also expected to be a valid address that can be > manipulated to get to the CStringData object for that string. Interesting. I must admit my first reaction is one of surprise. But I guess these days CString is a lot more than just a wrapper around a (TCHAR *) pointer, so maybe it makes sense in the implementation, not to allow the data pointer to be NULL. (Even so, I'll continue to allow for the possibility NULL when I use a cast to LPCTSTR - I feel safer that way.) :-) Dave -- David Webber Author of 'Mozart the Music Processor' http://www.mozart.co.uk For discussion/support see http://www.mozart.co.uk/mozartists/mailinglist.htm
From: Martin T. on 23 Sep 2009 09:02 David Webber wrote: > > "Scot T Brennecke" <ScotB(a)Spamhater.MVPs.org> wrote in message > news:uFh2%23Z1OKHA.4580(a)TK2MSFTNGP06.phx.gbl... > >> David Webber wrote: >>> >>> It isn't at all clear to me that the internal pointer of a CString >>> cannot legally be NULL. I've always thought it could be, and that >>> the CString methods allowed for it. >>> >>> I can't remember if I ever checked, but even if I did, it may be >>> different in different implementations. But I have always allowed >>> for the possibility that the standard cast >>> >>> (LPCTSTR)my_cstring; >>> >>> might return NULL. If it can, and you assume it doesn't, then you >>> might run into trouble. But (if I'm right) I can't think where >>> else the debugger might report a problem? >>> >>> Dave >> >> Nope. Check out the code for the ATL::CStringT (really the >> ATL::CSimpleStringT) class templates. You'll see that the m_pszData >> member should never be NULL. The (LPCTSTR) cast returns the m_pszData >> as a string pointer, but it's also expected to be a valid address that >> can be manipulated to get to the CStringData object for that string. > > Interesting. I must admit my first reaction is one of surprise. > > But I guess these days CString is a lot more than just a wrapper around > a (TCHAR *) pointer, so maybe it makes sense in the implementation, not > to allow the data pointer to be NULL. > MS implemented that ages ago. (before 1996 ?) The main reason as far as I can tell is that people used and continued to use CString Objects in printf and CString::Format(...) The only way to make this work is making a CString object binary compatible with a TCHAR pointer and also ensure that this pointer always points to a valid string, since there is no such thing as a NULL-string-CString object. > (Even so, I'll continue to allow for the possibility NULL when I use a > cast to LPCTSTR - I feel safer that way.) :-) > Weeeeell - A CString object (just as std::string, std::wstring or any other "normal" string class) should *never* yield a NULL pointer when asked for its string. So the check is kind of unnecessary. br, Martin
First
|
Prev
|
Pages: 1 2 Prev: pow function w/o math.h Next: C++/CLI - How to convert List<T> to vector<T> |