Dynamic mem allocation, how to get it right?

I have tried to dynamically set the size of an array depending on a input file´s size.
What I have done is, first using fseek() and ftell() to fetch the start and end of the data in the file.
I then subrtact start from end and store that in the variable size.

What I would like to know now is if using size in an array declaration actually works as I expect it to or if I have to use malloc().

This is what I tried first:

Code:

---

UInt8 dataArray[size];

// where size is the previously unknown size of the file or data

---

I wasn´t actually sure if this would work under all conditions, so I tried malloc like this:

Code:

---

UInt8 *dataArray = malloc(size);
void *dataPt = NULL;

dataPt = &dataArray;

---

I´m trying to use the void pointer to access different places in dataArray by increment it´s value here.

Code:

---

        for(dataCounter = 0; dataCounter < 120; dataCounter++) {
                        data[i].data[dataCounter] = *dataPt;
                        dataPt++;
                }

---

This gives me this warning: assignment makes integer from pointer without a cast

If I try to cast it I´m informed that I should not attempt to cast a void pointer? I thought that was what they where good for.











EDIT: This was weird, I just tried to compile this again and got a new error and warning like this:

warning: dereferencing ‘void *’ pointer
error: void value not ignored as it ought to be

If what you want is an int*, use and int*.

Quote:

---

Originally Posted by MK27

If what you want is an int*, use and int*.

---

Do you mean when I declare the pointer or when I attemt to dereference it?

If I give the same data type to the pointer and the array in the declaration I get a warning when I try to assign the address to it like this.

dataPt = &inData;

warning: assignment from incompatible pointer type

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
        int size=atoi(argv[1]), dataray[size], *ptr=dataray, i;
        for (i=0; i<size; i++) {
                *ptr=i;
                printf("%d\n",dataray[i]);
                ptr++;
        }
       
        return 0;
}

---

Compiles with no errors.
./a.out 4
0
1
2
3

Quote:

---

Originally Posted by MK27

Compiles with no errors.

---

Though there might be an error if one were compiling with respect to the 1990 edition of the C standard since a variable length array is used, but it would be fine with C99. Also, atoi() is found in <stdlib.h>, which was not included. There is also a potential problem in that argv[1] would be a null pointer if the user runs the program without any command line arguments.

Quote:

---

Originally Posted by MK27

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
        int size=atoi(argv[1]), dataray[size], *ptr=dataray, i;
        for (i=0; i<size; i++) {
                *ptr=i;
                printf("%d\n",dataray[i]);
                ptr++;
        }
       
        return 0;
}

---

---

If it´s ok to use a variable with unknown value at compile time to declare an array that´s good news. It worked for me as well, but I just wasn´t sure. Most of the time I have seen people using malloc() to do this. Also I might be missing something but it seems like *ptr isn´t actually doing anything, my problem comes in when I try to dereference the pointer to assign the value to a variable. Anyway if I can achive this without pointers and malloc() I´m going to stick with that. But it would be interesting to know how it could be achived.

The one with malloc is almost exactly the same (now stdlib.h is definitely needed):

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
        int size=atoi(argv[1]), *dataray=malloc(size*sizeof(int)), *ptr=dataray, i;
        for (i=0; i<size; i++) {
                *ptr=i;
                printf("%d\n",dataray[i]);
                ptr++;
        }
        free(dataray);
       
        return 0;
}

---

Remember, if you don't give an argument it will seg fault.

Quote:

---

Originally Posted by Subsonics

If it´s ok to use a variable with unknown value at compile time to declare an array that´s good news. It worked for me as well, but I just wasn´t sure.

---

As I noted in post #5, that is the variable length array feature introduced in the 1999 edition of the C Standard. There are limitations, e.g., the array cannot be expanded, unlike what you can do with say, realloc().

For a somewhat more robust version of MK27's malloc() example:

Code:

---

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>

int main(int argc, char *argv[]) {
    size_t size;
    int *data;
    size_t i;

    if (argc < 2) {
        puts("Please provide a non-negative integer command line argument.");
        return 0;
    }

    size = atol(argv[1]);
    data = malloc(size * sizeof(*data));
    if (data == NULL) {
        fprintf(stderr, "Error: unable to allocate memory.\n");
        return EXIT_FAILURE;
    }

    for (i = 0; i < size; ++i) {
        data[i] = i;
        printf("%d\n", data[i]);
    }

    free(data);

    return 0;
}

---

Quote:

---

Originally Posted by laserlight

As I noted in post #5, that is the variable length array feature introduced in the 1999 edition of the C Standard. There are limitations, e.g., the array cannot be expanded, unlike what you can do with say, realloc().

---

I somehow missed that earlier, I guess using it in a function that might be called several times during execution could mean trouble if filesizes increase. I´m going to experiment with this for a bit, thanks both of you for your input.

Code:

---

UInt8* dataArray = malloc(size);
void* dataPt = NULL;
dataPt = &dataArray;

---

This now stores the address of the pointer dataArray inside dataPt, so essentially it stores an Uint8**, masqueraded as void*.

Quote:

---

Code:

---

        for(dataCounter = 0; dataCounter < 120; dataCounter++) {
                        data[i].data[dataCounter] = *dataPt;
                        dataPt++;
                }

---

This gives me this warning: assignment makes integer from pointer without a cast

---

Quote:

---

EDIT: This was weird, I just tried to compile this again and got a new error and warning like this:

warning: dereferencing ‘void *’ pointer
error: void value not ignored as it ought to be

---

I don't know what exactly data & co are, but I do spot one problem.
dataPt++;
void* is a pointer to an unknown value, so it illegal to increment as well as dereference it. The compiler does not know the size of what it points to, so it cannot know how many bytes to advance with ++.
If you dereference a void* pointer, theoretically you would get void. But void is an illegal type that cannot be assigned to or from, so that compiler complains yet again.

Quote:

---

If I try to cast it I´m informed that I should not attempt to cast a void pointer? I thought that was what they where good for.

---

They are. Sort of.
Just remember that there's no guarantee what you cast to is what it actually is. You have to be careful to make sure it's right.

Quote:

---

so essentially it stores an int**,

---

actually UInt8**


and there is no need to cast void pointer in C while assigning it to another pointer

Quote:

---

Originally Posted by vart

actually UInt8**

---

Right. My mistake O_O

Quote:

---

and there is no need to cast void pointer in C while assigning it to another pointer

---

But technically, you still get the same effect as when you cast it, so the result is the same.

Quote:

---

Originally Posted by Elysia

I don't know what exactly data & co are, but I do spot one problem.
dataPt++;
void* is a pointer to an unknown value, so it illegal to increment as well as dereference it. The compiler does not know the size of what it points to, so it cannot know how many bytes to advance with ++.
If you dereference a void* pointer, theoretically you would get void. But void is an illegal type that cannot be assigned to or from, so that compiler complains yet again.

---

So would using += 1 work instead of ++ in this example? I still can´t compile the version with the void pointer, so I went back to declaring the pointer UInt8, since I´m not going to use it to point to anything else in this case. This still gives me a warning about incompatible pointer types for the assignement though. I have decided to ignore that for now however. Is the problem that I have allocated memory for what I´m pointing to? I mean in this case it´s not really one byte worth of memory in total which the pointer might suggest?

Quote:

---

Originally Posted by Elysia

They are. Sort of.
Just remember that there's no guarantee what you cast to is what it actually is. You have to be careful to make sure it's right.

---

Does this mean that dereferencing a void pointer always raise a compiler warning?

Quote:

---

So would using += 1 work instead of ++ in this example?

---

No, the pointer arithmetic does not work at all on the void pointer, because the size of the pointed object is unknown

Quote:

---

back to declaring the pointer UInt8

---

pointer to UInt8 and pointer to pointer to UInt8 are different things

Quote:

---

I have decided to ignore that for now however

---

Ignoring warnings that you do not understand is the easiest way to write a code that does absulutely different things from your intentions

Quote:

---

Is the problem that I have allocated memory for what I´m pointing to?

---

no

Quote:

---

Does this mean that dereferencing a void pointer always raise a compiler warning?

---

you cannot dereference void pointer - so it will raise error not warning

Quote:

---

Originally Posted by vart

No, the pointer arithmetic does not work at all on the void pointer, because the size of the pointed object is unknown

---

Hmm, ok. But at a first look it seems that explicitly adding one to whatever address the pointer contains should do what I want since what I´m pointing to is a byte array.

Quote:

---

Originally Posted by vart

pointer to UInt8 and pointer to pointer to UInt8 are different things

---

Not exactly sure what you are saying here. Do you mean that the allocated memory essentially is a pointer to the first address of an array. If so how should I declare it.

Quote:

---

Originally Posted by vart

Ignoring warnings that you do not understand is the easiest way to write a code that does absulutely different things from your intentions

---

Yes I know, but I said 'for now' meaning until I have found a solution.

Quote:

---

Originally Posted by Subsonics

Hmm, ok. But at a first look it seems that explicitly adding one to whatever address the pointer contains should do what I want since what I´m pointing to is a byte array.

---

But the compiler does not know that!
C is statically typed - the compiler knows only what type of information you have by looking at the type at compile time. If you cast it to void*, then the compiler has lost all track of the type.

Quote:

---

Not exactly sure what you are saying here. Do you mean that the allocated memory essentially is a pointer to the first address of an array. If so how should I declare it.

---

UInt8* is not the same as Uint8**.
The first is a pointer that points to one or more Uint8, and the second is a pointer that points to one or more Uint8*!

Quote:

---

Yes I know, but I said 'for now' meaning until I have found a solution.

---

That is not good enough!
This particular warning is more of an error, since it will 99% likely crash your program.
You must solve it right away before venturing further with the code.

Now, if you get that warning again, post the relevant code and we can point out what went wrong. A typical example that this warning says is this:

Code:

---

int* p = 0;
int x = p; // Warning: assignment makes integer from pointer without cast
p = x; // Warning: assignment makes pointer from integer without cast

---

Quote:

---

Originally Posted by Elysia

Now, if you get that warning again, post the relevant code and we can point out what went wrong.

---

Ok, the following gives me the warning. I guess I could do it in another way based on what have been presented earlier, but it´s interesting to see why things goes wrong.

Code:

---

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
        typedef unsigned char UInt8;
        int i;
        int size = 10;
        UInt8 *temp = malloc(size);
        UInt8 container[size];
        UInt8 *pt;
       
        pt = &temp; // <-- This raises the warning
       
        for(i = 0; i < size; i++) {
                container[i] = *pt;
                pt++;
        }
       
        free(&temp);       
        return 0;
}

---

Just to clarify this generates: warning: assignment from incompatible pointer type

I originally attempted to get past this by using a void pointer, but that just turned into a new problem that showed up in the for loop.

pt is of type pointer to UInt8. temp is also of type pointer to UInt8. As such, it does not make sense to assign the address of temp, which is of type pointer to pointer to UInt8, to pt. It might make sense to assign temp to pt.

Likewise, temp points to the first element of the array allocated by malloc(). It makes sense to write free(temp), but it does not make sense to write free(&temp), since temp itself is not dynamically allocated.

pt = &temp; // <-- This raises the warning

you should get rid of & in this line

Ahh, yes. It makes sence now. I just added the address of operator out of habit without thinking about the * in the declaration. Now this raises the question if *pt is needed at all in this example, or if I just as well could make the assignments from, and increment temp directly in the for loop?

I got rid of & in free() as well, I first got a warning about it not being there possibly from making the assignement from &temp to begin with. Anyway it works now! Perfect thank you all.

Quote:

---

I got rid of & in free() as well

---

you shuld leave the free

and for freeing original pointer - you need pt that will be incremented

Quote:

---

Originally Posted by Subsonics

Now this raises the question if *pt is needed at all in this example, or if I just as well could make the assignments from, and increment temp directly in the for loop?

---

If you change temp, you would have no way to free the memory from malloc(), unless you keep track of the change and "undo" it. I find it easier to just use another pointer like you did with pt, or to use an index, e.g.,

Code:

---

container[i] = temp[i];

---

Quote:

---

Originally Posted by vart

you shuld leave the free

---

Subsonics is talking about removing the address of operator from the argument to free(), not about removing the call to free().

Quote:

---

Originally Posted by vart

you shuld leave the free

and for freeing original pointer - you need pt that will be incremented

---

Ok, what I meant was the address of operator in the argument field of free().

BTW I just tried using temp directly in the for loop but got this error while freeing it.

Code:

---

       
        for(i = 0; i < size; i++) {
                container[i] = *temp;
                temp++;
        }

---

test(6364) malloc: *** error for object 0x10012a: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug

Adding

temp = NULL;

before freeing it got rid of the error but I´m not sure if it does what I want since I don´t inspect the content of container[] in this example.

Quote:

---

temp = NULL;

before freeing it got rid of the error but I´m not sure if it does what I want since I don´t inspect the content of container[] in this example.

---

of course it does not

as I said - you should leve 2 pointers - one is incremented - the other should store the address returned by malloc and should be passed to free

Quote:

---

Originally Posted by laserlight

If you change temp, you would have no way to free the memory from malloc(), unless you keep track of the change and "undo" it. I find it easier to just use another pointer like you did with pt, or to use an index, e.g.,

Code:

---

container[i] = temp[i];

---

---

Yes using an index makes what is going on pretty clear. I didn´t know that was possible before I saw it used in this thread. Thanks

Quote:

---

Originally Posted by vart

of course it does not

---

Well what can I say, things become simple once you understand them. ;-)

Quote:

---

Originally Posted by Subsonics

Ok, the following gives me the warning. I guess I could do it in another way based on what have been presented earlier, but it´s interesting to see why things goes wrong.

Code:

---

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
        typedef unsigned char UInt8;
        int i;
        int size = 10;
        UInt8 *temp = malloc(size);
        UInt8 container[size];
        UInt8 *pt;
       
        pt = &temp; // <-- This raises the warning
       
        for(i = 0; i < size; i++) {
                container[i] = *pt;
                pt++;
        }
       
        free(&temp);       
        return 0;
}

---

Just to clarify this generates: warning: assignment from incompatible pointer type

I originally attempted to get past this by using a void pointer, but that just turned into a new problem that showed up in the for loop.

---

You assign the address of a pointer to another pointer. Obviously, taking the address of a pointer will give you a pointer to that pointer. Which screws up everything afterwards, since dereferencing that pointer, pt, will give you the address of the pointer it points to, but the compiler will think that it is Uint8, which it is not!
And as for free, you must free what you malloc. Free expects the address that you originally got from malloc. So if you pass the address of the pointer that contains the address you got from malloc, what happens then? Nothing good at least.

Quote:

---

Originally Posted by Subsonics

Ok, what I meant was the address of operator in the argument field of free().

BTW I just tried using temp directly in the for loop but got this error while freeing it.

Code:

---

       
        for(i = 0; i < size; i++) {
                container[i] = *temp;
                temp++;
        }

---

test(6364) malloc: *** error for object 0x10012a: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug

Adding

temp = NULL;

before freeing it got rid of the error but I´m not sure if it does what I want since I don´t inspect the content of container[] in this example.

---

Again, free expects the address that was returned from malloc. If you increment the address, then you don't have the original address returned by malloc anymore! And what happens then? Nothing good at least.
And so you set it to NULL before calling free. That is going to help... how, exactly? Free needs the original address returned by malloc to identify what allocation it should free! And if pass NULL to free, how is it supposed to know what to free?
Free actually ignores a NULL pointer passed in and returns directly, which is why it works. But is it right? Hardly. You just created a memory leak. Why do you think it is a solution?

Quote:

---

Originally Posted by Elysia

And so you set it to NULL before calling free. That is going to help... how, exactly? Free needs the original address returned by malloc to identify what allocation it should free! And if pass NULL to free, how is it supposed to know what to free?
Free actually ignores a NULL pointer passed in and returns directly, which is why it works. But is it right? Hardly. You just created a memory leak. Why do you think it is a solution?

---

Actually, that make perfect sence. I made an attempt to use temp directly in the for loop simply to see for myself what would happen. I have one question about free() though, incrementing the address of the pointer I originaly allocated memory for means trouble, but where does the computer store information about the size of the allocated memory?

It's implementation-defined. But usually, it stores it right before the allocated memory itself. Sometimes even after the allocated memory.
This is the C runtime we're talking about. The OS stores its own information in memory, too, of course. And it, too, need some sort of handle to know what allocation to free. But the C runtime takes care of that.

Ok I see, is it possible to get the size of allocated memory somehow? I guess sizeof() wont work.

No portable way, no.
Some operating systems (such as Windows) allow you to do this. But it means you must use OS allocation functions since it's implementation-defined how malloc allocates its memory.
Some versions of the C library on some compiler vendors has a function to allow you to see how large it is, but again, this only exists as extensions.

So the answer would be: keep track of it yourself. That's how C++ does it, and so should you.

Ok thanks Elysia, in this example here I got it in the variable 'size' so that should be easy.