Строки ASCII и порядок байтов

Код профессора "C" выглядит примерно так? Если это так, ему необходимо обновить свой компилятор.

main() {
    extrn putchar;
    putchar('Hell');
    putchar('o, W');
    putchar('orld');
    putchar('!*n');
}

Профессор сбит с толку. Чтобы увидеть что-то вроде «P-yM azzi», вам нужно взять какой-то инструмент проверки памяти, который отображает память в режиме «4-байтового целого» и в то же время дает вам «символьную интерпретацию» каждого целого числа в старшем порядке. байт в байтовый режим младшего разряда.

Это, конечно, не имеет ничего общего с самой строкой. И говорить, что сама строка представлена ​​таким образом на машине с прямым порядком байтов, - полная чушь.

Вы можете легко доказать, что компилятор не выполняет таких «волшебных» преобразований, выполнив печать в функции, которая не знает, что ей передана строка:

int foo(const void *mem, int n)
{
    const char *cptr, *end;
    for (cptr = mem, end = cptr + n; cptr < end; cptr++)
        printf("%p : %c\n", cptr, *cptr);
}

int main()
{
    const char* s = "My-Pizza";

    foo(s, strlen(s));
    foo(s + 1, strlen(s) - 1);
}

В качестве альтернативы, вы даже можете скомпилировать сборку с помощью gcc -S и окончательно определить отсутствие магии.

Профессор ошибается, если мы говорим о системе, которая использует 8 бит на символ.

Я часто работаю со встроенными системами, которые на самом деле используют 16-битные символы, при этом каждое слово мало -индийский. В такой системе строка «My-Pizza» действительно будет храниться как «yMP-ziaz».

Но пока это система с 8 битами на символ, строка всегда будет храниться как «Моя -Pizza »независимо от порядка байтов в архитектуре более высокого уровня.

Я предполагаю, что профессор пытался сделать вывод по аналогии о проблеме с порядком байтов / NUXI, но вы правы, когда применяете это к реальным строкам. Не позволяйте этому сорваться из-за того факта, что он пытался научить студентов тому, как думать о проблеме определенным образом.

You may be interested, it is possible to emulate a little-endian architecture on a big-endian machine, or vice-versa. The compiler has to emit code which auto-magically messes with the least significant bits of char* pointers whenever it dereferences them: on a 32bit machine you'd map 00 <-> 11 and 01 <-> 10.

So, if you write the number 0x01020304 on a big-endian machine, and read back the "first" byte of that with this address-munging, then you get the least significant byte, 0x04. The C implementation is little-endian even though the hardware is big-endian.

You need a similar trick for short accesses. Unaligned accesses (if supported) may not refer to adjacent bytes. You also can't use native stores for types bigger than a word because they'd appear word-swapped when read back one byte at a time.

Obviously however, little-endian machines do not do this all the time, it's a very specialist requirement and it prevents you using the native ABI. Sounds to me as though the professor thinks of actual numbers as being "in fact" big-endian, and is deeply confused what a little-endian architecture really is and/or how its memory is being represented.

It's true that the string is "represented as" P-yM azzi on 32bit l-e machines, but only if by "represented" you mean "reading the words of the representation in order of increasing address, but printing the bytes of each word big-endian". As others have said, this is what some debugger memory views might do, so it is indeed a representation of the contents of the memory. But if you're going to represent the individual bytes, then it is more usual to list them in order of increasing address, no matter whether words are stored b-e or l-e, rather than represent each word as a multi-char literal. Certainly there is no pointer-fiddling going on, and if the professor's chosen representation has led him to think that there is some, then it has misled him.

Кроме того, (и я не играл с этим в течение долгого времени, так что могу ошибаться) Он может думать о пасколе, где строки представлены как "упакованные массивы", которые, IIRC - это символы, упакованные в 4-байтовые целые числа?

Трудно читать мысли профессора, и, конечно же, компилятор не делает ничего, кроме сохранения байтов по соседним возрастающим адресам в системах BE и LE, но это нормально для отображения памяти в числах размером со слово, независимо от размера слова, и мы записываем тысячу как 1000. Не 000,1.

$ cat > /tmp/pizza
My-Pizza^D
$ od -X /tmp/pizza
0000000 502d794d 617a7a69
0000010
$ 

Для записи y == 79, M == 4d.

AFAIK, порядок байтов имеет смысл только тогда, когда вы хотите разбить большое значение на маленькие. Поэтому я не думаю, что это влияет на строку в стиле C. Потому что в конце концов это просто массивы символов. Когда вы читаете только один байт, какое имеет значение, читаете вы его слева или справа?

Но, что шокирует, стажер утверждает, что профессор настаивает на том, чтобы строка будет представлен как:

P-yM azzi

Он будет представлен как, представлен как что? представляется пользователю как 32-битный целочисленный дамп? или представлен / макет в памяти компьютера как P-yM azzi?

Если бы профессор сказал, что "My-Pizza" будет представлен / макет как "P-yM azzi" в памяти компьютера, потому что компьютер имеет архитектуру с прямым порядком байтов, кто-то Пожалуйста, научите этого профессора пользоваться отладчиком! Думаю, отсюда и все замешательства профессора, у меня есть подозрение, что профессор не программист (не то чтобы я смотрю вниз на профессора), я думаю, что у него нет способа доказать на коде то, что он узнал о порядке байтов.

Возможно, профессор выучил принцип байтов примерно неделю назад, а потом просто неправильно использовал отладчик,