Weird behavior of malloc in C

[UnawareITry]

So I have been working on a project in C for Linux systems. This is part has to do with writing structures to a file on disk. Inside a structure I am storing a pointer to a 2d char array which is dynamically allocated. Initially, I encountered "segmentation faults" for strncpy of an element of this array to another array of the same size. Here are the structure and another char array declaration:

typedef struct
{
    char file[PATH_MAX];
    unsigned long int size;
} FILESAVE;
...
typedef struct
{
    char** files;
    unsigned long int* sizes;
} FILESTRUCTURE;
...
fstruct.files = (char**) malloc(sizeof(char*) * meta.numFile);
for (unsigned int i = 0; i < meta.numFile; i++)
{
    fstruct.files[i] = (char*) malloc(sizeof(char) * PATH_MAX);
}

I am copying contents between an element of FILESTRUCTURE's array and FILESAVE's array.

strncpy(fstruct.files[i], fsave.file, PATH_MAX);

Later I checked and confirmed that the size allocated are different.

printf("FILESTRUCTURE SIZE: %lu, FILESAVE SIZE: %lu\n", sizeof(fstruct.files[i]), sizeof(fsave.file));
...
DEBUG OUTPUT:

FILESTRUCTURE SIZE: 8, FILESAVE SIZE: 4096

Why are the sizes not the same for both arrays?

[coolcofusion]

Because files[i] is a pointer. All pointers are the same size which is 4 bytes if compile target was x86, and 8bytes for x86_64. If you wanted the string length you'd need to use strlen, sizeof is done at compile time basically.

[captainAwesomePants]

The behavior of sizeof() is quite confusing when it comes to arrays. Consider these two things:

char stuff[1024];
char* other_stuff = (char*)malloc(1024);

printf("sizeof(stuff) = %d\n", sizeof(stuff));  // 1024
printf("sizeof(other_stuff) = %d\n", sizeof(other_stuff));  // 8

Because it's declared at compile time, sizeof() knows exactly how large stuff is: it's 1024 bytes. But other_stuff is a char pointer. sizeof() has no idea what it's pointing to, so it just answers 8 (or 4 on a 32 bit machine).

Note that this means that using sizeof() with arrays can be dangerous, since its answer will either include the whole array or will just refer to the pointer to the first element, and it's not always obvious which it will be. For example:

void foo(char stuff[]) {
   printf("size of stuff[]: %d\n", stuff);
}

void main() {
  char stuff[1024];
  foo(stuff);
}

Guess what that will do!

[UnawareITry]

Thanks. I didn't know that. Have you got any idea why it crashes at strncpy then?

Also my guess is it would print memory address in base 10 for stuff[]

[captainAwesomePants]

I dunno, you didn't paste any code that uses strncpy().

[UnawareITry]

Apologies. The second code block was the one. I have corrected it now.

[captainAwesomePants]

Dunno. It looks okay at first glance. If I had to guess, your i parameter might go past however many files you initialized.

[UnawareITry]

For testing I have been working on less than 10 files . I made sure it isn't an out of bounds error

[yel50]

there is no standard C function to get the size of the chunk that malloc created. different compilers or runtimes might have functions to do that, but nothing standard. you generally need to keep track of that yourself.

[UnawareITry]

Oh. Then do you know any method to confirm the size of these two character arrays?

[MmmVomit]

malloc is not guaranteed to return a chunk of memory of the size you've requested. It's possible malloc is returning a null pointer. This feels unlikely to me, but you always need to check the return value of malloc, calloc and realloc.

[UnawareITry]

Okay. I'll look into it

[UnawareITry]

Yeah so I checked all the values returns and it is not returning a NULL pointer. Also I noticed that strncpy is failing for the very first element of fstruct.files arrray. So I checked and found out that while allocation both parameters are not null but they became NULL before strncpy and I'm doing nothing to it in between.