Size of an object/variable from its pointer?

Does anyone know if its possible to find the size of an variable from a pointer to the said object. I have the below code (and similar code in my_malloc, which for obvouse reasons is simpler to implement) ovcourse the below returns the size of the pointer not the object, can anyone help?

Code:

---

void my_free(void *ptr){
        div_t temp;
       
        if (memmoryusage == NULL){
                memmoryusage = 0;
        }
       
        memmoryusage = memmoryusage - sizeof(&ptr);

        temp = div( memmoryusage, 100 );
        printf("(F) MEMORY = %d, %d, %d%\n", memmoryusage, sizeof(&ptr), temp.quot);
        free(ptr);
       
}

---

If ptr points to an object then by dereferencing and taking its sizeof gives the size of the said object as in

Code:

---

char *ptr, c;
ptr = &c;
sizeof *ptr; /* gives you the sizeof the character c */

---

Quote:

---

Originally Posted by cerberus_jh

Does anyone know if its possible to find the size of an variable from a pointer to the said object.

---

No it is not possible. I recommend having a map of pointers allocated by my_malloc() that associates them with the size.

Quote:

---

Originally Posted by itCbitC

If ptr points to an object then by dereferencing and taking its sizeof gives the size of the said object as in

Code:

---

char *ptr, c;
ptr = &c;
sizeof *ptr; /* gives you the sizeof the character c */

---

---

1) You don't need *ptr to be a valid pointer for size_of to work. size_of does not evaluate its expression.
2) In that case you may as well do size_of char, since you know the type.
3) In the OP case, he can't do that because void pointers are not dereferenceable.

Quote:

---

Originally Posted by itCbitC

If ptr points to an object then by dereferencing and taking its sizeof gives the size of the said object

---

No, that just gives the size of the type the pointer is pointing to. That doesn't mean the object itself is of that type.

Quote:

---

Originally Posted by brewbuck

No, that just gives the size of the type the pointer is pointing to. That doesn't mean the object itself is of that type.

---

This is C, so it does. There is no polymorphism.

Quote:

---

Originally Posted by King Mir

This is C, so it does. There is no polymorphism.

---

Uh, no.

Code:

---

struct A
{
    int x;
    int y;
};

struct B
{
    struct A base;
    int z;
};

B *newB = malloc(sizeof(B));
...
A *basePtr = (A *)newB;
sizeof(*basePtr) /* is not equal to the size of the object pointed to */

---

Well yes, if you cast, you change the type of the object in the context of the expression. But that's semantics.

The point is well made that size_of does not magically guess the size of the original malloc.

And what about this?

Code:

---

double *dynarr;
dynarr = malloc(sizeof(double) * 200);
printf("size=%d\n", sizeof(*dynarr));

---

Normally, malloc & free rely on storing the size (and possibly some other bits of data) in a block of memory immediately before the memory returned to the "client". That's the correct way to do it.

Code:

---

        if (memmoryusage == NULL){
                memmoryusage = 0;
        }

---

That's surely incorrect.


--
Mats

Perhaps it's compiler and/or machine dependent. I tried it on my machine and both the C and C++ compiler give correct results for sizeof *basePtr;

Quote:

---

Originally Posted by brewbuck

Uh, no.

Code:

---

struct A
{
    int x;
    int y;
};

struct B
{
    struct A base;
    int z;
};

B *newB = malloc(sizeof(B));
...
A *basePtr = (A *)newB;
sizeof(*basePtr) /* is not equal to the size of the object pointed to */

---

---

What do you consider "correct size"? I would expect the compiler to print 8, but the allocated size is 12.

--
Mats

Correct *newB is 12 and *basePtr is 8 bytes.

Quote:

---

Originally Posted by itCbitC

Correct *newB is 12 and *basePtr is 8 bytes.

---

So that is exactly what the original poster DOESN'T want.

--
Mats

This is a great example for those learning the language to take the time to use gdb and perhaps printing out the assemply language to see how memory is placed on the stack for such a small piece of code like this. This will shed light on what the sizes amount to and why.

Gdb? ...Nah.
Visual Studio is far better ;)
Of for the lack of a better word, this is a great example why people should take time to use a debugger!