The attached patche fixes a bug I found with purify. The initial problem is that the method: operator >>(nsInputStream&,nsPersistentFileDescriptor&) reads a string into a char* but does not null terminate it. We use this string on line 62 of nsFileSpecStreaming.cpp and the lack of a null terminator causes the program to run past the end of our string. This is easy enough to fix by null terminating the string, and thats one thing this patch does. The next thing I noticed is that the place where we are running off the end of the string is in a copy constructor that seems to be totally unnecessary. If you follow the code what happens when we make the call: d.SetData(bigBuffer, bytesRead); is that bigBuffer is automatically turned into a nsSimpleCharString for the SetData method, and inside the SetData method, it is immediatly cast back into a char*. I added another SetData method which takes a char* instead of an nsSimpleCharString, and this eleminates the creation of a temporary nsSimpleCharString.

I presume you want me to do the honors? Accepting bug, with thanks. Changing component to XP File Handling, target to M6 Changing summary from "Fix for UMR found by Purify" to "nsPersistentFileDescriptor overwrites buffer!". Changing severity to "normal", priority to P2, platform to "All".

John, I think you'll find this bug to be very very similar to a previous one I'd discussed with you where the temporary resolution was a memset() to 0 ifdef'd for Solaris.

Bruce, that bug concerned an apparent reading (by _fullpath) of a buffer whose first byte had been set to zero. I'm not sure there's more than the most superficial resemblance here. Please enlighten me.

Moving to M7 (I can't check in because of the reorg).

I checked this in.

code fix

Bulk moving to XPCOM, in preparation for removal of XP File Handling component. (XPFH has received two bugs in ~5 months, and is no longer in active use.)