Declaration of char in memory

Question

Guys I declare a char example : char a ; , it is only 1 byte in size , and supposing it is on a 32-bit architecture , it would not have lost address space , 3 bytes of the address would not be free and only 1 busy?

Answer 1

You are confusing addressing with alignment (which is reasonable, myself 10 minutes ago was also confused). One thing is to determine the size of each address, i.e. if you have a variable, register, etc that stores an address, how many distinct bytes this variable can represent. Another is to determine what exactly is being represented - an individual byte? a set of X bytes? etc.

Addressing

Think of computer memory as a long list of bytes:

3f  79  bf  34  aa  60  14  b0  6d  68  c4  5c  1a  21  59  e7  ...
0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  ...

And let’s say you want to refer to one of these bytes, say the 6th (index 5, contains the value 0x60). You’ll need to store this address somewhere. Let’s say you use 1 byte variables only to store addresses. Then somewhere in your memory there will be a data occupying 1 byte with the value 0x05:

3f  79  bf  34  aa  60  14  b0  6d  68  c4  5c  1a  21  59  e7  ... 8a  9a  05  dd  c3
0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  ... X-2 X-1 X   X+1 X+2
                                                                            ^

This would be an "8-bit architecture". It is easy to notice that in that case the supported memory size would be tiny - only 256 bytes are addressable... But what if instead of using 1 byte to store addresses you use 2 bytes?

3f  79  bf  34  aa  60  14  b0  6d  68  c4  5c  1a  21  59  e7  ... 8a  00  05  dd  c3
0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  ... X-1 X   X+1 X+2 X+3
                                                                        ^^^^^^^

This would be a "16-bit architecture". Now you can address up to 65536 different bytes, but each address occupies 2 bytes instead of 1. See in the example above, as the address of your variable now does not refer to the whole data (0x00 0x05) but rather to the first part of it (0x00). The second part (0x05) is not directly referenced, but is implicit by the 16-bit architecture that if a given represents an address, then it must occupy 2 bytes, starting with the one being referenced (X).

(and opening a parenthesis, note that we could represent this address for both 0x00 0x05 and 0x05 0x00; the use of one or the other is that characterizes an architecture big endian or little endian)

If you are programming in a lower level language, such as C, you can even do "illegal" things, such as trying to access X+1 directly (0x05). The result would be unpredictable, "catastrophic" perhaps, but it would be your fault for not following the conventions of your architecture (since the "address" in X+1 is 0x05 0xdd, which can point to an invalid memory region).

Alignment

Now imagine that instead of memory we are talking about a hard disk, which may have terabytes or even petabytes or beyond:

76           4a           37            9a  9b  5b  fe  60  b0  f9  3b  14  d1  3e  62  3a
253050123000 253050123001 253050123002  ...

In this case it would be very impractical to address each individual byte of the disk - first because it doesn’t make much sense, hardly anyone will want to access "the byte in the X address" outside the context of a file, for example; second because, to support larger and larger disks, You’d need really big addresses, which wastes space. The solution then is to make not every byte [directly] addressable, but to split the file system into blocks - or clusters - with a fixed size for each block, and instead of saying "the file stored in byte X until Y" we say "the file stored in block X". In this case, the Operating System knows that to get to the file it is necessary to multiply the block index by the size of each block.

The computer’s memory, I assume (as I said, until recently this also confused me) does not suffer alignment by default. Some applications can align your data for better management. For example, I noticed that in the JVM each object always occupies a minimum of 24 bytes, and always grows 8 in 8 bytes (i.e. you can’t have an object with 27 bytes, for example, or is 24 or 32). These specific systems may choose to use fewer bytes to represent each address, in exchange for not being able to have all bytes of memory directly addressable. Is a tradeoff which may or may not make sense, depending on the case.

Completion

Then answering your question, there is no waste as your char occupied 1 byte, the 3 bytes in front (and behind) remain available to store other data and other variables, and this data is also directly addressable. Whether a memory region is "occupied" or not depends solely on the alignment that the system gives to it, if any.

Note: This is a simplified explanation, which does not take into account indirect or virtual memory. In practice, physical memory management is a little more complicated than "the X-address points to the X-th byte in memory". Fortunately, from the programmer’s point of view, this normally happens transparently - the OS gives the programmer the illusion that the entire memory is at his disposal, and every thing is in the place you put it. All "magic" happens underneath the scenes, at least when programming normal applications and not lower-level things - as components of the OS itself.