I have code in my hand that uses ncCAutoStrings and tries to append a nsCAutoString to another nsCAutoString with the += operator, but it doesn't append anything. I've had reports that this code doesn't fail in linux so it might be a specific problem with Windows 2000/VC++ 6.0SP3. Example to display what I mean, this is not the actual code causing the bug: nsCAutoString string("Hello"); nsCAutoString another_string("World"); string += " "; string += another_string; string += "!"; Expected result: string = "Hello World!" Actual result: string = "Hello !" The difference I see between appending char* constants and nsCAutoString begins in nsCString::do_AppendFromReadable( const nsAReadableCString& aReadable ) where the former calls nsAWritableCString::do_AppendFromReadable(aReadable) which works fine and the latter calls StrAppend(*this, NS_STATIC_CAST(const nsCString&, aReadable), 0, aReadable.Length()); which doesn't work. Other interesting things are that the append causes a "GrowCapacity" and a "Realloc" and that the string to append is appended to the new buffer made by Realloc _but_ after returning from StrAppend, the original string still uses the same buffer as before. My amateurish analysis says that the bug is to be found somewhere in nsStr::GrowCapacity but since that function is old and (I guess) has been in use for a long, long time I think I'm wrong.
Nominating for nsbeta2 since it's important that the string classes work correctly.
The bug manifests after fixing bug 31906 in that all font prefs fail and a default proportial font is used. Good catch, Daniel.
I can't seem to write a test that fails for this case based solely on your example. Can you point me to the source for the real failure? Perhaps it has some difference we haven't noticed and did not account for here.
scc, the source is not yet checked in. See the "Final patch" for bug 31906. There, in function |*_begin| (of both mimetpla and mimtpfl), I try to add |fontstyle| to |openingDiv|, IIRC. This seems to fail, as Daniel reports (worksforme).
I wonder if I've been crying wolf here. I looked at string.mBuffer in the debugger while debugging, but when I dig deeper it seems like the full string is stored somewhere else, because printing the string shows the full one. It was such a logical explanation for the bug I was looking for that I never took time to really study what happened. I'm sorry.
markin invalid per my earlier comment.
- Per last comments, age of bug, and no reopen - Marking Verified/invalid. Please reopen if still a problem.