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.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
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?
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.
News on this? Or verify. You can always file a new bug, if this annoys somewhen someone...
You need to log in before you can comment on or make changes to this bug.