suppose i have this value stored in my memory how will memory determine this is string or int .How datatype are stored in memory
-
Types are a property only your compiler is aware of, and it dictates what operations it outputs into your compiled binary. Computer memory is just raw bits. – StoryTeller - Unslander Monica Aug 29 '16 at 12:26
-
2Heard of `MSB`/`LSB`...what is `MSD`? – Sourav Ghosh Aug 29 '16 at 12:27
-
1@SouravGhosh I assume D is for Digit. Which isn't that wrong, just unusual. – StoryTeller - Unslander Monica Aug 29 '16 at 12:28
-
1@SouravGhosh MSB/LSB will show its signed or unsigned but how datatype will be dteremined? – Ayaz Ahmad Tarar Aug 29 '16 at 12:30
-
3@AyazAhmadTarar it doesn't show whether it's signed or unsigned. – harold Aug 29 '16 at 12:34
-
The task of any program is to take a chunk of raw binary numbers and use them in a way that makes sense to that program. The memory and the CPU are completely dumb and know nothing of such things. – Lundin Aug 29 '16 at 12:36
-
1Possible duplicate of [Identifying data type of a value in memory in C?](http://stackoverflow.com/questions/9761605/identifying-data-type-of-a-value-in-memory-in-c), see also http://programmers.stackexchange.com/questions/291950/are-data-type-declarators-like-int-and-char-stored-in-ram-when-a-c-program-e – Cody Gray - on strike Aug 29 '16 at 12:36
-
@CodyGray: Hmm, I maybe should have closed the other one as a duplicate of this. IDK, they both have some reasonable answers. Nice find of a good dup-target though. – Peter Cordes Aug 30 '16 at 01:05
4 Answers
suppose i have this value stored in my memory how will memory determine this is string or int
It doesn't.
How datatype are stored in memory
If type information is stored and how is completely up to the programming language and runtime environment used. All implementations of C (compiler and standard library) I know of do not store the data type alongside the values. Other programming languages and rumtimes do.
But with C how contents of memory are interpreted is determined entirely by the program, i.e. the machine level operations performed on the contents of a particular memory location. And it is up to the programmer (you) not to lie to the compiler about what can be found in memory locations.

- 159,371
- 13
- 185
- 298
-
1This is why C is called a "statically typed" language: all type information is always known at compile-time, not determined dynamically. (Contrast with C++'s `dynamic_cast`, [which does use type info stored in memory (by the compiler, in a standard location, so it's still not *the memory itself* that knows anything about types](http://stackoverflow.com/questions/3747066/c-cannot-convert-from-base-a-to-derived-type-b-via-virtual-base-a)) – Peter Cordes Aug 30 '16 at 01:09
There is no need for the memory to know what type of data is being stored and where. Memory is just about storing values in blocks with addresses.
Its the compilers job to determine the type and fetch the appropriate data from memory.

- 425
- 1
- 4
- 17
bits is bits. Not only does it not have a specific type as the memory is concerned it can have many types all at the same time. The notion of types is mostly only relevant to the human, and at times to the logic, but never to the memory.
You might have a program where you have a variable that is an address, the base address for a structure lets say. But when you want to access an item in that structure, some bits are collected from memory that you the human recognize as address bits, but then they go into logic that does addition so that the offset into what you consider to be a structure can be computed. That adder only sees those bits as operands, neither signed nor unsigned as an adder doesnt know the difference thanks to twos complement, the addition is performed and in your human mind those bits are an address, but to the logic they are just bits, maybe landing in a register or maybe just one step in a register+offset load or store instruction. those bits might need to go through an mmu to be converted from virtual to physical. Those bits are not just an offset in a table, more math, operands into an adder, then some of the bits get replaced to make them a physical address, most of your bits you considered an address are now gone, replaced.
In grade school I had a pencil, many actually, but on one particular day one could imagine one pencil. On the bus ride to school it might have been a pain my leg in my pocket sitting down. Maybe that same pencil then became a back scratcher. Or perhaps something to gnaw on like a dog bone. Then eventually it may have been used to write down spelling words, an english pencil. Then in math class it was used to add numbers, an addition pencil. Art class to do art, an art pencil. Science. History, etc. Just like bits in memory, general purpose, only the context in which they are used for one clock cycle defines them by logic as something else, and then they are just bits again.

- 69,149
- 8
- 89
- 168
As mentioned: It doesn't. This Task is up to the compiler and programmer. On the one hand, this can lead to program faults, but on the other hand this allows some tricks like:
//Change a lowercase Character to uppercase character:
char x = 'a';
printf("%c\n", x);
x += 32;
printf("%c\n", x);

- 803
- 1
- 9
- 23
-
Type-punning with a union would be a better example. This doesn't demonstrate anything special, IMO. `char` is already an integer type that holds character values, and `'a'` is a character constant in whatever the platform's native character encoding is. (You're assuming ASCII, rather than EBCDIC or something. Of course, any mucking around with reinterpreting the bits of a value's representation is always non-portable, like using an integer operation to flip the sign bit of an IEEE `float`.). – Peter Cordes Aug 30 '16 at 01:03
-
Well, you're right. Was just the simplest example that came to my mind – Jounathaen Aug 30 '16 at 11:00
-
I'm arguing that this isn't an example at all of what's being talked about. A `char` is just an integer type, so it's not weird or special to add 32 to it. – Peter Cordes Aug 30 '16 at 11:04