Find DWORD Size - visual-c++

I am new in vc++... I have one doubt in vc++. what is the size of GetTickCount() function.The return type of GetTickCount() is DWORD. Please anyone Answer for my question.
Thanks in Advance

The size of a function means the number of bytes occupied by the code that belongs to the function. You can find this out using a debugger like Windbg. But this is not useful information in most cases. To get the size of a data type, you can use the sizeof operator. Since the return type of GetTickCount is DWORD (4 bytes), you can either do sizeof(DWORD) or sizeof(GetTickCount()) to get its size. There is also a function by the name GetTickCount64 which returns ULONGLONG which is a 64-bit unsigned value (8 bytes).

GetTickCount() returns a DWORD which is 4 bytes. The function itself can be represented using its start address (function pointer) which will have size equal to size of void* which is 4 bytes on 32-bit systems and 8 bytes on 64-bit systems. Finding the size of code that the function occupies can be problematic and is rarely needed.

Related

MMAP fails in attempt to double buffer framebufer

I am trying to implement a double buffer using ioctl(fd, FBIOPAN_DISPLAY...
my single buffer code works fine
screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
fbp = (char*)mmap(0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED, fbfd, 0);
when I try to increase the "length parameter" by using screensize*2, the mmap fails with EINVAL. I think it doesn't like my length parameter.
The screen size for a single buffer is 6,220,800 and for the double buffer is 12,441600. This is an embedded system but it has 1 Gig of RAM.
The length parameter is size_t which on this system is only 4 bytes which would make me think that the max size I could use would be 4 Meg, yet 6 Meg works fine so I think I am missing something really simple. Is there a way to mmap a buffer larger than size_t?
The man page says that length (the 2nd parameter) is of type size_t, so I don't think you are safe to pass a larger type.
I would suggest you to just map the first part, and then remap the second part as shown in this SO Q&A.
Regarding the EINVAL:
Following is stated in the man page:
EINVAL
We don't like addr, length, or offset (e.g., they are too large, or not aligned on a page boundary).
EINVAL
(since Linux 2.6.12) length was 0.
EINVAL
flags contained neither MAP_PRIVATE or MAP_SHARED, or contained both of these values.
Are you sure you are page alligned?

Why use sizeof(int) in a malloc call?

I am new to C++ and also in MPI programming. I have confused about this code block in C++
int count;
count=4;
local_array=(int*)malloc(count*sizeof(int));
Why are we using sizeof(int) here in MPI programming?
I could see that you're trying to allocate 4 ints here.
If you look at malloc's signature, it takes the number of bytes for its first parameter. As stated here, int data type takes 4 bytes.
Therefore, if you want 4 ints, you could have typed local_array=(int*)malloc(count*4);. But not everyone remembers that int actualy takes 4 bytes. That's why you use sizeof to find out the actual size of the object or type.

How can DWORD ever hold values more than 32 bits?

The NSFDbSpaceUsage function in the Lotus Notes C API is defined as:
STATUS LNPUBLIC NSFDbSpaceUsage(
DBHANDLE hDB,
DWORD far *retAllocatedBytes,
DWORD far *retFreeByes);
This function returns the number of bytes allocated and the number of bytes free in a specified database.
Reading SO and elsewhere, I understand that DWORD is associated with unsigned long, which is (usually) 32 bits. What puzzles me is how the above function will ever return the size of a Domino database that is more than 2^32 bytes in size. And in fact, my sample application never returns anything greater than 2,147,483,647 (2^31) for some of my larger databases. An NSF file in Domino can grow to 64 GB, so why would IBM use a DWORD to report the number of bytes allocated, when a DWORD can't represent more than 4,294,967,296 (2^32) bytes?
What am I missing?
I'm guessing this API method was created back when 4 GBs was larger than anyone could ever imagine ;)
According to the comments here, this method is limited to only 4 GBs and there is another method to use: NSFDbSpaceUsageScaled

C Why the casting of malloc and an explanation?

Ok I asked this the other day. But the answers I recieved when asked made me realize I was not fit to question it yet until I did some hard research.
So here I am yet again to retry this....
In examples of malloc I seen something as such...
#include <stdio.h>
int main()
{
int ptr_doe;
ptr_doe = (int *) malloc(sizeof(int));
}
I read that it was not neccesary for the:
(this *) malloc(sizeof(int));
And that only
(int *) malloc(sizeof(\\this));
is neccesary. Is the casting before calling the malloc function ever neccesary?
And how do we know how much memory we need to allocate and what the hell is this?
malloc(10 * sizeof(int));
is it multiplying 4 bytes by 10? and when is it neccesary to use malloc? How does it work internally? Thanks for any help guys
1.
Is the casting before calling the malloc function ever neccesary?
If you use a currect compiler, No. See answers to Do I cast the result of malloc?
2.
how do we know how much memory we need to allocate
It depends on your needs.
3.
malloc(10 * sizeof(int));
means to allocate memory big enough to store 10 int value.
4.
is it multiplying 4 bytes by 10?
If sizeof(int) equals 4, yes.
5.
when is it neccesary to use malloc?
If only at runtime you can know how much memory your program needs.
6.
How does it work internally?
Briefly, malloc() will ask operating system for enough memory, record some information it needs, and return you a pointer to the start of that memory segment.

Memory allocation in VC++

I am working with VC++ 2005
I have overloaded the new and delete operators.
All is fine.
My question is related to some of the magic VC++ is adding to the memory allocation.
When I use the C++ call:
data = new _T [size];
The return (for example) from the global memory allocation is 071f2ea0 but data is set to 071f2ea4
When overloaded delete [] is called the 071f2ea0 address is passed in.
Another note is when using something like:
data = new _T;
both data an the return from the global memory allocation are the same.
I am pretty sure Microsoft is adding something at the head of the memory allocation to use for book keeping. My question is, does anyone know of the rules Microsoft is using.
I want to pass in the value of "data" into some memory testing routines so I need to get back to the original memory reference from the global allocation call.
I could assume the 4 byte are an index but I wanted to make sure. I could easily be a flag plus offset, or count or and index into some other table, or just an alignment to cache line of the CPU. I need to find out for sure. I have not been able to find any references to outline the details.
I also think on one of my other runs that the offset was 6 bytes not 4
The 4 bytes most likely contains the total number of objects in the allocation so delete [] will be able to loop over all objects in the array calling their destructor..
To get back the original address, you could keep a lookup-table keyed on address / 16, which stores the base address and length. This will enable you to find the original allocation. You need to ensure that your allocation+4 doesn't cross a 16-byte boundary, however.
EDIT:
I went ahead and wrote a test program that creates 50 objects with a destructor via new, and calls delete []. The destructor just calls printf, so it won't be optimized away.
#include <stdio.h>
class MySimpleClass
{
public:
~MySimpleClass() {printf("Hi\n");}
};
int main()
{
MySimpleClass* arr = new MySimpleClass[50];
delete [] arr;
return 0;
}
The partial disassembly is below, cleaned up to be a bit more legible. As you can see, VC++ is storing array count in the initial 4 byes.
; Allocation
mov ecx, 36h ; Size of allocation
call scratch!operator new
test rax,rax ; Don't write 4 bytes if NULL.
je scratch!main+0x25
mov dword ptr [rax],32h ; Store 50 in first 4 bytes
add rax,4 ; Increment pointer by 4
; Free
lea rdi,[rax-4] ; Grab previous 4 bytes of allocation
mov ebx,dword ptr [rdi] ; Store in loop counter
jmp StartLoop ; Jump to beginning of loop
Loop:
lea rcx,[scratch!`string' (00000000`ffe11170)] ; 1st param to printf
call qword ptr [scratch!_imp_printf; Destructor
StartLoop:
sub ebx,1 ; Decrement loop counter
jns Loop ; Loop while not negative
This book keeping is distinct from the book keeping that malloc or HeapAlloc do. Those allocators don't care about objects and arrays. They only see blobs of memory with a total size. VC++ can't query the heap manager for the total size of the allocation because that would mean that the heap manager would be bound to allocate a block exactly the size that you requested. The heap manager shouldn't have this limitation - if you ask for 240 bytes to allocate for 20 12 byte objects, it should be free to return a 256 byte block that it has immediately available.
The 4 bytes offset is for the number of elements. When delete[] is invoked it is necessary to know the exact number of elements to be able to call the destructors for exactly the necessary number of objects.
Since the memory allocator could have returned a bigger block than necessary for storing all the objects the only sure way to know the number of elements is to store it in the beginning of the block.
For sure, memory allocation does need some bookkeeping info stored together with the actual memory.
Next to that, heap allocated blocks will also be 'decorated' with some magic values, used to easily detect buffer overruns, double deletion, ... Take a look at this CodeGuru site for more info. If you want to know the last of heap debugging, take a look at the msdn documentation.
The finial answer is:
When you do a malloc (which new uses under the hoods) allocates more memory than needed for the system to manage memory. This debug information is not what I am interested. What I am interested is the difference between using the return from malloc on a C++ array allocation.
What I have been able to determine is sometimes the C++ adds/uses 4 additional byte to keep count of the objects being allocated. The twist is these 4 bytes are only added if the objects being allocated require being destructed.
So given:
void* _cdecl operator new(size_t size)
{
void *ptr = malloc(size);
return(ptr);
}
for the case of:
object * data = new object [size]
data will be ptr plus 4 bytes (assuming object required a destructor)
while:
char *data = new char [size]
data will equal ptr because no destructor is required.
Again, I am not interested in the memory tracking malloc adds to manage memory.

Resources