What is the byte order - I understand. But I absolutely do not understand how to "correctly" represent the addressing of bytes in the computer's memory. I have always believed that the correct presentation is from left to right , but now I’m not so sure.

For example:

// Допустим, эта переменная лежит в памяти по адресу 2... // И имеет порядок Little-Endian uint16_t u16 = 256; 

Then, it turns out that:

 Номер байта: 0 1 2 3 4 5 6... Значение: xx 0 1 xx x... ^ &u16 вернет этот адрес 

Is this the correct presentation?

This situation can also be represented as follows:

 Номер байта: ...6 5 4 3 2 1 0 Значение: ...xxx 1 0 xx ^ &u16 вернет этот адрес 

And then the brain breaks ...

In general, the questions are:

1) Is the idea that byte addressing of memory goes from left to right correctly? At least when considering c .

2) Where is the description of what specifically returns the operator for receiving the address of an object & object ? Does this statement return the address of the byte of the object closest to the origin ? Or what?

  • 2
    This is all very conditional. In our culture, we can assume that the bytes are placed from left to right and the address of the object is the address of the leftmost byte. The byte order inside integers is completely different. - Mark Shevchenko

1 answer 1

1) Is the idea that byte addressing of memory goes from left to right correctly?

Of course no. In memory DOES NOT EXIST the concepts of "left" and "right". In memory, there are only "addresses" from 0 to a certain maximum. Your question simply does not make sense. What color is the electron? Yellow? Or green?

2) Where is the description of what specifically returns the operator for receiving the address of an object & object?

Absolutely in all standards of C it is written that the operator "&" returns ADDRESS. Are you interested in how this ADDRESS works? It is necessary to look at the specific processor. As in different processors, the addressing is organized in different ways. The only thing that can be guaranteed is: loading such an ADDRESS to the index register, when added to the base address, will give the correct address of the object in the process memory. It is the process, not the processor, since the virtual memory manager still interferes with the concept of "address".

In short, as the bus passengers used to say in Soviet times:

  • Old man, leave the empty nonsense!
  • Come in - from the back,
  • Go - from the front!

    :-)

It is to me that knowingly in the language any operations with addresses are prohibited , except for increment and subtraction of two addresses. And these operations are allowed only because the address is strictly associated with the TYPE to which it refers. Therefore, the compiler can increment or calculate the difference. Any other pointer operations can have unexpected consequences.

  • You can link to the official source, which states that any operations other than math pointers with pointers are prohibited? - user294535
  • You can link to the official source - These authors are: "Brian V. Kernigan, Dennis M. Ritchie" - are you quite authoritative for you? In section 5.4. They write their bibles: "You can perform the following operations with pointers: assigning a pointer value to another pointer of the same type, adding and subtracting a pointer and integer, subtracting and comparing two pointers pointing to elements of the same array, and assigning a pointer to zero and comparison of the pointer with zero. Other operations with pointers are not allowed . " - Sergey
  • Okay, what about the billions of C code in which it is assumed that (1) the address of an elementary type is the address of its first byte (2) the address of the structure is the address of the first byte of its first element (3). Plus, according to the Standard, compilers, it is forbidden to change the order of the elements of structures, and this requirement was introduced for a reason, but because all existing C code, and possibly all C ++ code, works with a certain byte arrangement in objects of elementary types, as well as structures, in a certain order. The only thing that can affect the interpretation of data is the byte order. - user294535
  • For example, are there also doing illegal operations ?: ibm.com/developerworks/ru/library/au-endianc - user294535
  • do illegal operations here too? It would be nice, before you argue with such fervor, to read what the founding fathers write one more time and compare with the code :-) You didn’t notice that you use the char one [4] arrays to work with bytes ; etc.? And the authors of the language write: pointing to the elements of the same array . So what's the problem? - Sergey