On Wed, 2002-08-28 at 19:30, Rick Matthews wrote: > > -----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.
A pointer points to a single memory location -- the first one allocated, in this case. The pointer doesn't know that the next n bytes of memory are also yours. > 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. You haven't done that. You've requested, and been given, n bytes. You've then written n+1 bytes into memory, starting at the first location. Except you actually wrote n+2, because (from strcat(3) manpage) "The strcat() function...then adds a terminating '\0' character." So in your example, 14 bytes is the length of the string -- but that's more than the memory you were allocated. If something else owns the memory immediately after yours, then that program can write over the bytes you put in its area. The joy and pain of C/C++ is that you can do all sorts of wonderful things -- and some of them won't be what a rational person would expect! > Why would it require you to define the length during allocation if > it is never going to enforce the allocation? A pointer cannot enforce an allocation. The malloc() call is distinct from the use of the memory. Some nasty bugs appear due to this feature :) I'm sure Morris will correct me if I've said anything bogus. HTH, HAND Greg Sheard Technical Director ECSC Ltd. www.ecsc.co.uk #include <legal_disclaimer.h>
signature.asc
Description: This is a digitally signed message part
