nsCString::Append(PRUnichar) ends up calling CopyChars2To2

RESOLVED INVALID

Status

()

Core
String
P3
major
RESOLVED INVALID
19 years ago
a year ago

People

(Reporter: Chris Waterson, Assigned: rickg)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
This is unexpected, because nsCString should be on a one-byte buffer (expected
CopyChars2To1). To reproduce, just set a breakpoint in CopyChars2To2 and keep
hitting 'F5'. I hit this in the very first call from the registry.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
(Assignee)

Comment 1

19 years ago
After running the debugger and talking to Waterson, we've concluded that the
debugger is doing odd things atop an optimized build. In non-optimized, the
exactly correct thing is occuring. JBand, have you any insight to shed on
optimized builds messaging the function?

Comment 2

19 years ago
I don't have a lot of insight on this. I haven't used the debugger *that* much
on optimized builds. I do know that it can sometimes lie about what source goes
with what object code. I'd be inclined look at the disasm in the debugger to see
if it is executing the code that goes with the source or not. Assuming that
mCharSize is always correctly set I don't see anything in the code that would
make me think it might execute a different path in optimized than debug.

Comment 3

18 years ago
News on this? Or verify. You can always file a new bug, if this annoys somewhen
someone...

Updated

13 years ago
Component: XP Miscellany → String
You need to log in before you can comment on or make changes to this bug.