Pelles C forum
C language => Windows questions => Topic started by: karnak on April 10, 2014, 12:39:46 AM
-
hi,
I recently discovered the _msize() function which returns the size of dynamically allocated memory, and decided to write a small test program to check it out. However instead of giving me the correct sizes of 10 and 20 it actually gives 16 and 24.
I decided to see what mingw 32-bit would give so I ran it in Codeblocks which did indeed return the correct values of 10 and 20.
(had to include <malloc.h> and change the format specifier from %zu to %u)
Anyone any ideas?
#include <stdio.h>
#include <stdlib.h>
//#include <malloc.h>
#define SIZE_ONE 10
#define SIZE_TWO 20
int main(void)
{
char* array_ptr;
char* temp;
int i;
size_t array_size;
array_ptr = malloc(sizeof(char) * SIZE_ONE);
if(array_ptr == NULL)
{
fprintf(stderr,"Malloc error - Out Of Memory.");
exit(EXIT_FAILURE);
}
array_size = _msize(array_ptr);
printf("malloc'd array size = %zu\n\n",array_size);
for(i = 0;i < SIZE_ONE;i++)
{
array_ptr[i] = '0' + i;
printf(" %c",array_ptr[i]);
}
printf("\n\n");
temp = array_ptr;
array_ptr = realloc(array_ptr,sizeof(char) * SIZE_TWO);
if(array_ptr == NULL)
{
fprintf(stderr,"Realloc error - Out Of Memory.");
free(temp);
exit(EXIT_FAILURE);
}
array_size = _msize(array_ptr);
printf("malloc'd array size = %zu\n\n",array_size);
for(i = SIZE_ONE;i < SIZE_TWO;i++)
{
array_ptr[i] = 'A' + i - SIZE_ONE;
printf(" %c",array_ptr[i]);
}
printf("\n\n");
for(i = 0;i < SIZE_TWO;i++)
{
printf(" %c",array_ptr[i]);
}
printf("\n\n");
return 0;
}
-
hi,
I recently discovered the _msize() function which returns the size of dynamically allocated memory, and decided to write a small test program to check it out. However instead of giving me the correct sizes of 10 and 20 it actually gives 16 and 24.
When _msize works correctly is does not reaturn what you said in malloc(), it returns the actual size of the memory block allocated by the system. Depending on windows versions this could be in blocks of 8, 16 or 32 characters. Thus if you ask for 1 you will get 8, 10 will get you 16, 20 will get you the next multiple of 8 which is 24.
It's harmless unless you are trying to figure out something like the length of a struct... for that you would use sizeof() or for the length of a string you would use strlen(). For an array size (per your example) use Sizeof(element) * NumberOfElements.
-
Gotcha - its the blocks allocated rather than the bytes requested.
Still - wonder why there is a difference between Pelles C and Codeblocks - on the same 64 bit win7 computer?
I would have thought the allocated memory fetch would be handled by the OS.
Edit: I just checked and for 1 byte requested allocation _msize returns 16 in Pelles C and 1 in Codeblocks. So it seems in Pelles C its returning the blocks allocated and in Codeblocks its returning the bytes requested.
btw I know good programming practise would avoid it, but I wondered if that means that in any malloc'd allocation that didn't allocate a full block those 1 - 15 bytes or whatever are actually available for use? I wouldn't do it, but I can't think of a reason why they wouldn't be usable?
-
As CommonTater explained the memory allocater reserves so many baytes to guarantee that the next allocation request will get memory starting on a boundary suiting for any kind of data.
Normally this is 8 byte for 32 bits, 16 for 64 bits systems.
To use the spare memory is a good programming practice to roud allocation request to the minimal allocable block,
Anyway _msize as per MS definition, that PellesC follows in this case, returns the size of blocks allocated not the bytes requested (see here (http://msdn.microsoft.com/en-us/library/z2s077bc.aspx)).
I would add that if you use the function to check for memory leaks or usage to get the real space allocated is more indicative.
While you can use OS functions to allocate memory, C standard memory allocator (malloc, calloc, etc) allocates a big chunk from the OS than creates substructures to handle memory requests allocated from that chunk. For small or frequent allocation/reallocations this could be much more efficient than enter the OS each time.
-
...guarantee that the next allocation request will get memory starting on a boundary suiting for any kind of data.
Normally this is 8 byte for 32 bits, 16 for 64 bits systems.
MSDN, malloc: (http://msdn.microsoft.com/en-us/library/6ewkz86d%28v=vs.110%29.aspx)The storage space pointed to by the return value is guaranteed to be suitably aligned for storage of any type of object.
That's a bold statement, and I'd like to test it with _mm_load_ps aka movaps but get compile errors.
PellesC\Include\xmmintrin.h uses _mm_load_ps but it seems to be undefined.
-
That's a bold statement, and I'd like to test it with _mm_load_ps aka movaps but get compile errors.
PellesC\Include\xmmintrin.h uses _mm_load_ps but it seems to be undefined.
you have to include <xmmintrin.h>.
Probably my statement above in uncorrect, PellesC must align always on 16bytes boundary for 32 and 64 bits if xmm set have to be supported.
In case of misalignement will be trigged an exception (GP fault from CPU).
I just made a quick check, the function _mm_load_ps is defined only for 64bits.
So malloc for 32 maybe uses 8byte alignement.
Anyway you should be able to use these functions on 32 bits using this trick:
#define tmp __POCC_TARGET__
#undef __POCC_TARGET__
#define __POCC_TARGET__ 3
#include <xmmintrin.h>
#undef __POCC_TARGET__
#define __POCC_TARGET__ tmp
Then you must use _mm_malloc and _mm_free to allocate memory for your dynamic variables (for static or local variables prepend __declspec(align(16)) ).
I have took a look at the headers, but not tested it. Maybe doesn't work if Pelle removed the functionalities from compiler and the _mm_malloc from 32 bits libraries.
-
Frankie,
This is less complicated:
long long q=0x1234567812345678;
__asm movaps xmm0, q;
However, the problem is elsewhere:
int main(int argc, char* argv[]) {
long long *q=malloc(32);
__asm movaps xmm0, q;
}
Works fine in 50% of all cases (while for the other 50%, malloc returns a pointer to an 8- but not 16-byte aligned memory area, in spite of Microsoft's bold promises...).
-
That's a bold statement, and I'd like to test it with _mm_load_ps aka movaps but get compile errors.
PellesC\Include\xmmintrin.h uses _mm_load_ps but it seems to be undefined.
Ok, moving on.....
-
Gotcha - its the blocks allocated rather than the bytes requested.
Still - wonder why there is a difference between Pelles C and Codeblocks - on the same 64 bit win7 computer?
Look in the Pelles C help file. There is an appendix that explains Pelle's memory allocator. Although I can't find the link right now there is also a writeup that explains the MinGW allocator. You should probably study up on both.
Most modern compilers are using Heaps, which behave as Frankie and I have explained. By aligning the data on certain boundaries the OS can be far more efficient at accessing memory and, yes, the performance differences are noticeable on repetative memory intense tasks.
Heaps are explained here...
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366711(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366711(v=vs.85).aspx)
What matters most is that it _msize returns actual space allocated, not space used.
-
btw I know good programming practise would avoid it, but I wondered if that means that in any malloc'd allocation that didn't allocate a full block those 1 - 15 bytes or whatever are actually available for use? I wouldn't do it, but I can't think of a reason why they wouldn't be usable?
You could probably use them... in fact some system exploits do exactly that. 15 bytes is enough space to set up a jmp instruction to malicious code.
But you are correct, it would be horrificly bad practice to try.
-
Frankie,
This is less complicated:
long long q=0x1234567812345678;
__asm movaps xmm0, q;
However, the problem is elsewhere:
int main(int argc, char* argv[]) {
long long *q=malloc(32);
__asm movaps xmm0, q;
}
Works fine in 50% of all cases (while for the other 50%, malloc returns a pointer to an 8- but not 16-byte aligned memory area, in spite of Microsoft's bold promises...).
Damn it JJ ... this is a forum for C programming. Nobody gives a flying rats ass about your irrelevent asm garbage. It just confuses people and if the moderators had even the first lick of sense they would declare it "off topic".
As you've been told before ... Learn C or get lost!
-
Damn it JJ ... this is a forum for C programming. Nobody gives a flying rats ass about your irrelevent asm garbage. It just confuses people and if the moderators had even the first lick of sense they would declare it "off topic".
As you've been told before ... Learn C or get lost!
Tater,
Get a shrink before it's too late. You may be a reasonable coder but your social skills are below zero.
On topic: The point is that malloc uses HeapAlloc under the hood, which returns 8-byte aligned memory. Has nothing to do with assembly or C but it causes bugs that are difficult to chase.
-
Damn it JJ ... this is a forum for C programming. Nobody gives a flying rats ass about your irrelevent asm garbage. It just confuses people and if the moderators had even the first lick of sense they would declare it "off topic".
As you've been told before ... Learn C or get lost!
This forum is not a pure C forum. I personally appreciate JJs contributions and it is always an enrichment for me, to learn something new, asm for example.
-
Damn it JJ ... this is a forum for C programming. Nobody gives a flying rats ass about your irrelevent asm garbage. It just confuses people and if the moderators had even the first lick of sense they would declare it "off topic".
As you've been told before ... Learn C or get lost!
This forum is not a pure C forum. I personally appreciate JJs contributions and it is always an enrichment for me, to learn something new, asm for example.
Then you should join the MASM forum where JJ is 100% on topic... but just as ridiculous.
-
On topic: The point is that malloc uses HeapAlloc under the hood, which returns 8-byte aligned memory. Has nothing to do with assembly or C but it causes bugs that are difficult to chase.
On topic ... the user did not ask for a mass discussion of various memory allocation schemes. He just wanted to know why _msize gave him an unexpected result. He was asking about a C language function... Get it? Not ASM... C. You diverging off into your usual bullshit about asm only confuses and does not give meaningful answers.
You are not helping anyone and you should simply stop posting.
-
CommonBlaker,
Until recently this forum was a peaceful place with intelligent contributions. You showed up again, and since then you have not stopped showing off how brilliant you are, and how stupid are all others. There are some here (Pelle himself included but not me) who have worked really hard on add-ons and headers in order to make Pelles C even better. You are ridiculing their efforts. Apparently foul language and insults are all you can "contribute". Seriously, seek professional help.
-
Damn it JJ ...
Tater, Get a shrink
Gentlemen, I respect you both. I understand that there are personalities that naturally tend to rub each other the wrong way. Even in my own house. I have often repeated the following proverb to my sons. Where there is no wood, the fire goes out.
I never regret the times that I have abided by that proverb; but often regret the times I did not. If I might be so bold, please wait at least 5 minutes before replying to each other's posts, you might find that it is not even worth the effort.
-
CommonBlaker,
Until recently this forum was a peaceful place with intelligent contributions. You showed up again, and since then you have not stopped showing off how brilliant you are, and how stupid are all others. There are some here (Pelle himself included but not me) who have worked really hard on add-ons and headers in order to make Pelles C even better. You are ridiculing their efforts. Apparently foul language and insults are all you can "contribute". Seriously, seek professional help.
Well, JJ, "...wer im Glashaus sitzt sollte nicht mit Steinen werfen..."
Ralf
-
CommonBlaker,
... foul language and insults are all you can "contribute". Seriously, seek professional help.
Well, JJ, "...wer im Glashaus sitzt sollte nicht mit Steinen werfen..."
Ralf,
I agree that "people who live in glass houses shouldn't throw stones". Show me one example where I used foul language and insults. Or, more precisely, show me one post addressed to you that would give you the right to accuse me (as you have implicitly done above) of using foul language (your highlighting).
Here are examples of foul language, generated in the last few days.
@Stefan:
it is kinda silly.
@jj:
NOBODY said that JJ ... please work on your literacy skills.
@jj:
Damn it JJ ... this is a forum for C programming. Nobody gives a flying rats ass about your irrelevent asm garbage.
@jj:
You diverging off into your usual bullshit
@czerny:
Oh boy ... this is getting really stupid.
We've had this conversation before and you have repeatedly demonstrated a very low comprehension ... you are 15 years behind the times.
My friend, it's time to either grow up or give up.
@several of us:
JJ2007 seems to think that posting ASM code makes him look smarter than us...
czerny continues to misunderstand, clinging to an anachronism and lecturing people... if he can't keep up, that's his problem not ours.
Suddenly we are giving users personal platforms to tout their own software. The new "projects in pelles c" forum is both redundent and counterproductive.
The moderators here are inert. Sometimes I wonder how their brains generate enough energy to get them typing...
The last one, "The moderators ... how their brains generate enough energy" was also addressed to you, I guess.
-
CommonBlaker,
... foul language and insults are all you can "contribute". Seriously, seek professional help.
Well, JJ, "...wer im Glashaus sitzt sollte nicht mit Steinen werfen..."
Ralf,
I agree that "people who live in glass houses shouldn't throw stones". Show me one example where I used foul language and insults.
CommonBlaker,
...
Or, more precisely, show me one post addressed to you that would give you the right to accuse me (as you have implicitly done above) of using foul language (your highlighting).
It doesn't matter if it was addresses to me or not.
I do not agree with JD's antics, but there is absolutely no reason for you to pour more oil into the fire either.
Now let's cut out with all of this and get back to programming in (Pelle's) C, that's the purpose of this forum.
Ralf