why is the result of sizeof(char *) 2 ??
- Thread starter rajeshjsl
- Start date
abhaybhegde
Adept
You got that thing wrong.
Size of pointer does not depend on what it points to. Size of pointer ( irrespective of data type ) depends on two things
1. Natural word length of the machine. 2. Compilation target .
So if you are on a 32 bit machine and compilation target is 32 bit , sizeof(pointer) = 4 bytes( 32bits = 4 bytes) . If its a 64 bit then it's 8 bytes.
abhaybhegde
Adept
Yes , provided the program you are compiling has the same compilation target.
For ex., If the native machine size is 32 bit , but your compilation target is 16 bit or 8 bit it will be different.
Gryph0n
Adept
To confuse both of you further, theoretically the size of the pointer can vary depending on whats being pointed to.
For eg, DSP's have a different addressing bus for code and data, and it could be possible that the sizes of the corresponding pointers could be different. (DSP's use Havard architecture, while normal CPU's use Von-Neumann architecture)
Closer home, there are a variety of segmented addressing modes in the x86 processor's real mode (16 bit DOS), and in some of those modes, the sizes of data & code segments could be very different. Practically, no one uses the archaic 'real mode' segmented addressing on x86/x64 processors, so chances of seeing this scenario is very rare.
Question 5.17
PS, this is an obscurity. If you are ever asked the same question in an interview, the "correct" answer would be that all pointers have the same size.
I have no idea about DSP, but on x86 real mode,
what do you meant when you say, "the sizes of data & code segments could be very different"
What does it has to do with the size of pointer? Your code segment will have instructions to execute and data segment will have the variables (global, static), they will off course have different size in almost all cases, and that has nothing to do with the size of pointer.
In real mode; You can access up to 16 bit addresses using the normal pointer, or you can use a address in a different selector using far pointer. The size of pointer is still same, irrespective of type.
I guess I missed your point, perhaps?
---------- Post added at 10:50 PM ---------- Previous post was at 10:32 PM ----------
Perhaps you are referring to Intel Memory Model - Wikipedia, the free encyclopedia, compact and medium model? Old days, eh?
OP: You can go with what Abhay told you, that is true in all modern OSes (PC), as they all run in protected mode now days. What Gryph0n is saying is not false; but considering you are starting right now (and there is no need of far and near pointer now), you can skip it. You may read it later on.
what do you meant when you say, "the sizes of data & code segments could be very different"
What does it has to do with the size of pointer? Your code segment will have instructions to execute and data segment will have the variables (global, static), they will off course have different size in almost all cases, and that has nothing to do with the size of pointer.
In real mode; You can access up to 16 bit addresses using the normal pointer, or you can use a address in a different selector using far pointer. The size of pointer is still same, irrespective of type.
I guess I missed your point, perhaps?
---------- Post added at 10:50 PM ---------- Previous post was at 10:32 PM ----------
Perhaps you are referring to Intel Memory Model - Wikipedia, the free encyclopedia, compact and medium model? Old days, eh?
OP: You can go with what Abhay told you, that is true in all modern OSes (PC), as they all run in protected mode now days. What Gryph0n is saying is not false; but considering you are starting right now (and there is no need of far and near pointer now), you can skip it. You may read it later on.
Let me put my 2cents:
1. In olden days 16bit processors had 16 bit address bus, which implies addresseble memory was 2[SUP]16[/SUP] which is equal to 65,536 which means earlier 16bit computers were able to address 64kB of ram.
2. Intel guys came with an innovative solution to the above problem by implementing segmentation with which the people were able to address 2[SUP]20[/SUP] addresses which is equal to 1,048,576 means the computers were now able to address 1mB of ram with just 16 address lines. this method was called Memory segmentation. The address was divided to segment and offset where first byte resented segment and next byte represented the offset. do not confuse this segmentation with Memory segmentation - Wikipedia, the free encyclopedia, both are different.
3. With the introduction of 32bit processor (x86) the address bus increased to 32bits or a double word (dword) where the addressible memory is now 2[SUP]32[/SUP] which is equivalent to 4gB of address space. Windows and Linux uses flat addressing where you can simply go to any address in this range. but, Windows split this 4gb space to two parts, first 2gb as kernel space and remaining 2gb as user space. since most computers dont have 4GB of memory and to avoid lots of problems with memory segmentation, the OS uses page tables to address data. where the address used by applications is virtual address and the address stored in the page tables is the real address. (now dont confuse yourself with this virtual real addresses with the 16 bit era.)
With the RAM getting cheaper, people started putting more than 4GB ram into machines and wondering why they were unable to use it. to solve this again, windows implemented a similar thing called PAE (Physical address extenstion)
4. 64bit processors theoritically support 16TB of RAM. but they still use PAE which I could never really understand.:unsure:
1. In olden days 16bit processors had 16 bit address bus, which implies addresseble memory was 2[SUP]16[/SUP] which is equal to 65,536 which means earlier 16bit computers were able to address 64kB of ram.
2. Intel guys came with an innovative solution to the above problem by implementing segmentation with which the people were able to address 2[SUP]20[/SUP] addresses which is equal to 1,048,576 means the computers were now able to address 1mB of ram with just 16 address lines. this method was called Memory segmentation. The address was divided to segment and offset where first byte resented segment and next byte represented the offset. do not confuse this segmentation with Memory segmentation - Wikipedia, the free encyclopedia, both are different.
3. With the introduction of 32bit processor (x86) the address bus increased to 32bits or a double word (dword) where the addressible memory is now 2[SUP]32[/SUP] which is equivalent to 4gB of address space. Windows and Linux uses flat addressing where you can simply go to any address in this range. but, Windows split this 4gb space to two parts, first 2gb as kernel space and remaining 2gb as user space. since most computers dont have 4GB of memory and to avoid lots of problems with memory segmentation, the OS uses page tables to address data. where the address used by applications is virtual address and the address stored in the page tables is the real address. (now dont confuse yourself with this virtual real addresses with the 16 bit era.)
With the RAM getting cheaper, people started putting more than 4GB ram into machines and wondering why they were unable to use it. to solve this again, windows implemented a similar thing called PAE (Physical address extenstion)
4. 64bit processors theoritically support 16TB of RAM. but they still use PAE which I could never really understand.:unsure:
Gryph0n
Adept
In some modes of segmented addressing, you can have different sizes for data pointers (16/8 bit) and function pointers (typically 32 bits).
Even for data pointers, you can have 'near' and 'far' pointers, meaning the pointers are either intra-segment, or inter-segment. The sizes of these 'near' (8 bits i think)and 'far' pointers (16 bits i think) would be different.
The link I've posted in my previous post has some more examples of (old) hardware that has different pointer sizes depending on the data types (and also some examples of hardware where the NULL pointer isn't actually at address 0x0).
The point is that the C language makes no guarantees about pointer sizes being equal for all types. Although nowadays you'll mostly encounter hardware/modes with same pointer sizes, it doesn't necessarily have to be so.
@booo
>>since most computers dont have 4GB of memory and to avoid lots of problems with memory segmentation, the OS uses page tables to address data.
Not sure what problem of segmentation are you talking about here? PTEs are always used if OS is in protected mode, now its benefits are process address space isolation, setting page protection (user/kernel bits), and more. Which otherwise would have to be done in software itself.
>>64bit processors theoritically support 16TB of RAM. but they still use PAE which I could never really understand.
Backward compatibility?
@Gryph0n,
>>Although nowadays you'll mostly encounter hardware/modes with same pointer sizes, it doesn't necessarily have to be so.
Yep, got your point after I posted(hence the update)
>>since most computers dont have 4GB of memory and to avoid lots of problems with memory segmentation, the OS uses page tables to address data.
Not sure what problem of segmentation are you talking about here? PTEs are always used if OS is in protected mode, now its benefits are process address space isolation, setting page protection (user/kernel bits), and more. Which otherwise would have to be done in software itself.
>>64bit processors theoritically support 16TB of RAM. but they still use PAE which I could never really understand.
Backward compatibility?
@Gryph0n,
>>Although nowadays you'll mostly encounter hardware/modes with same pointer sizes, it doesn't necessarily have to be so.
Yep, got your point after I posted(hence the update)
Last edited by a moderator: