If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

string += another_string doesn't append anything (nsCAutoString)

VERIFIED INVALID

Status

()

Core
XPCOM
P3
critical
VERIFIED INVALID
18 years ago
17 years ago

People

(Reporter: Daniel Bratell, Assigned: Scott Collins)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Nominating for nsbeta2 since it's important that the string classes work 
correctly.
Blocks: 31906
Keywords: nsbeta2

Comment 2

18 years ago
The bug manifests after fixing bug 31906 in that all font prefs fail and a

default proportial font is used.



Good catch, Daniel.

(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M16
(Assignee)

Comment 3

18 years ago
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.

Comment 4

18 years ago
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).
(Reporter)

Comment 5

18 years ago
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.
 
(Reporter)

Comment 6

18 years ago
markin invalid per my earlier comment.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Keywords: nsbeta2
Resolution: --- → INVALID

Comment 7

17 years ago
- Per last comments, age of bug, and no reopen - Marking Verified/invalid.  
Please reopen if still a problem.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.