> -----Original Message----- > From: Gilles CHAUVIN > Sent: Wednesday, August 28, 2002 10:20 AM > > On Wed, Aug 28, 2002 at 10:13:30AM -0400, Morris Maynard wrote: > > I think that Gilles found and fixed the problem correctly. The change > > where he increased the size of the memory allocated to match the length of > > the filename string is the key. Without that change, the byte just past > > the end of the memory allocated doesn't really belong to the program, and > > so could be written over by another process, or even by other code in the > > same process. This is why the problem shows itself so randomly and why the > > filename's ending character in the error log report differs from report to > > report. > > > Thanks... That's exactly (or almost ;) what I thought but, as english > isn't my native language, I didn't know the words to explain this. > You've done this for me, thanks ! :)
As I have previously mentioned to Morris, here's why I do not believe that is the case: As I understand it, this statement: update = (char *) sgMalloc(strlen(file) + 5); allocates a block of space and returns a pointer in "update". You never see "update" mentioned with a length component, so the pointer must be self-contained. So if I pass it a 13 character variable and tell it to store it in a space that I've previously defined as 12 characters, I cannot believe that it would happily store the 13 bytes in a 12 byte slot without the first complaint. And later when I ask it to retrieve the data stored at "pointer" (which is defined as starting position, length 12), I can't believe that it would return 14 bytes, again without a single complaint. Why would it require you to define the length during allocation if it is never going to enforce the allocation? Rick
