After some futher testing and stepping through the code, we've noticed that
when the string::t0 is copied from another string::t0 that the full
string::t2 structure was not copied, therfore missing the final element of
string::t2.data_ (null term character) So whatever information that was
there prior to the copy, it stayed there (in some cases a luck null char,
other times a random byte).
After surround the two structures with a pragma pack 1 (since the short_size
is a bit field), it seems to have fixed the problem. Now my problem is
(basically UI in the debugger or some existing type library that is being
used by the debugger) that when viewing this data in the debug watch window,
the short_size structure still appears as two bytes. therefore making it
appear as if I have truncated the start of my data_, but when you look in
memory, all is well. (hence if I set a lpcstr to the string.c_str() of this
object, the value is correct.).
Is there anything I can do to correct the debugger problem?
Any help would be Greatly! appreciated..
The snippet of code in the string file is below.
problem could be solved by modifying the string file (~line 993) to pack the
short_size and short_t structs.
#pragma pack (1)
struct short_size
{
unsigned char f_ : 1;
unsigned char size_ : __char<>::bits - 1;
};
struct short_t
{
union
{
short_size s;
value_type pad;
};
value_type data_[min_cap];
};
#pragma pack ()
thanks - bill
"Ben Combee" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> At 12:40 2003-3-19 -0800, you wrote:
> >Has metrowerks updated the STL that is included with the product?
> >Is this their own?
>
> This is our own STL, part of the Metrowerks Standard Library, and
> maintained by C++ library experts like Howard Hinnant.
>
> >I've having some really strange problems with the string class, and need
to
> >know if there's been an update to the template? (or if you use
Dinkumwares
> >etc, if there's an update.)
>
> There have been updates to MSL internally, but we have not issued a V9
> patch that has these updates yet. They will be part of the V9.2 release,
> but I'm not sure if the bug you're reporting is fixed yet.
>
> >Here is what I'm doing and what I'm seeing:
> >
> >DatabaseInfo dbi;
> >
> > dbi.uicardno = volRefNum;
> >dbi.dbID = 0;
> >dbi.strfilename = pszNameSrc;
> >dbi.strpath = pszVol;
> >
> >pszNameSrc is a char[], as well as strpath, this dbi structure is added
to a
> >vector of these DatabaseInfo structures.
> >strfilename and strpath are string
> >
> >If I verify the value of pszNameSrc, and the value of dbi.strfilename
after
> >this code, they are the same and appear correctly.
> >
> >After I loop through all the databases and build this vector of these
> >DatabaseInfo objects, (for testing) I then loop through this vector and
> >verify the information in the dbi structure.
> >
> >for some reason (once in awhile, but on the very same filenames), I get
> >garbage at the end of strfilename. (e.g. database1.pdb becomes
> >database1.pdb*&*$ )
>
> This seems similar to a bug that just got reported on Mac OS with that
> version of MSL, but the code in that MSL is actually older than this
> version, and the fix didn't apply.
>
> >(but I know for a fact that the char[] is clean and has been zero'ed out
> >prior to puting the name into it.) - I've actually stepped through the
code,
> >added this structure, then looked at the structure in the vector AND
looked
> >at the original structure and the original structure would be clean and
the
> >one in the vector would have the garbage.
>
> The problem is the internal buffer allocated in the string object that
> holds a copy of your data.
>
> I suggest that you turn off inlining and step into the code that does the
> string assignment to see what's happening. I just did a cursory look at
> the code, and I don't see anything obviously wrong. If you can't figure
it
> out, I'd send an example in to CW tech support who can forward it to the
> right engineer.
>
> --
> Ben Combee <[EMAIL PROTECTED]>
> CodeWarrior for Palm OS technical lead
> Palm OS programming help @ www.palmoswerks.com
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
