memory copy

given the following

Code:

---

typedef struct
{
    char    fileName[ 1024];
    time_t  deleteTime;
} file_item_t;

....
....

setFileEntry(    char                    *fileName)
{
    file_item_t    file;
 
    memset( &file, 0x00, sizeof( file_item_t ));

    memcpy( file.fileName,
            fileName,
            sizeof( file.fileName ) - 1 );
...
...

---

when the function is called, it runs ok on sparc machine but segment faults on amd i386 both running Solaris 10
fileName is a null term string.

While it copies more data than is required, the destination buf is sufficent to hold it.
So not sure why there would be a problem on that point.
if I replace the memcpy with a strcpy the bug is removed.

or if replace the sizeof with strlen+1, it works ok too.

is it possible that memcpy behaves differently on the different architectures?

You mean:

Code:

---

    memcpy( file.fileName,
            fileName,
            strlen(fileName));

---

BTW, why not using strcpy()?

Two things.....
1) Never rely on sizeof() to tell you the size of an array. It works fine in this case, but it's a very bad habit to get into, and it'll bite you later if you do.
2) Try adding the following after the memcpy:

Code:

---

file.filename[1023] = 0;

---

since that's the only notably difference between strncpy() and memcpy(). (You should never use strcpy()-,only strncpy(), if you're stuck with C-style strings.)

well strlen does not include the null so that is why I said strlen(fileName) + 1.

It legacy code and this bug is exposed when running the s/w on amd machine.

strcpy works fine as I say when I patch.
or even using the strlen(fileName) + 1 with the memcpy

I presume the memcpy copies the chunk of data (including the sring + NULL char) and then what ever comes after.
Wouldnt the

Code:

---


file.filename[1023] = 0;

---

just set the char at that index to NULL.
The original memcpy would copy string+NULL+whatever else upto the size specified.

But what if the string in the input fileName is longer than 1023 characters? Then memcpy *wouldn't* write a NULL anywhere.

strcpy() would also be wrong in that case, because it would overrun the bounds of the array, but it might still appear correct if you didn't happen to corrupt anything important.

Also, what if the input fileName doesn't have 1024 characters allocated? An attempt to read beyond that range using memcpy() could conceivably trigger a segfault on some systems.

I understand what you are saying.
but is it not is this case per test.
so I'm still unclear as to why it would work on sparc and not on amd.

Just reading your last point again.
why would the read beyond that point cause a failure on some systems?

Quote:

---

well strlen does not include the null so that is why I said strlen(fileName) + 1.

---

+1 is not necessary. You don't have to copy the null termination char, which is 0, because your buffer is already filled with 0 (see the memset above) ;).

Segmentation faults indicate that a program tried to do something to memory it isn't allowed to access. Some systems would only cause a segfault if you *write* to invalid memory; however, it's entirely possible that others would do the same merely by trying to read from it.

If the input string fileName only has 20 bytes allocated and you try to read the next 1024 bytes, that could be an issue.

ok I understand, thanks alot for the replies Lindley and cilu.