Строки ASCII и порядок следования байтов

Стажер, работающий со мной, показал мне сданный им экзамен по информатике, посвященный проблемам порядка следования байтов. Был вопрос, который показывал строку ASCII "My-Pizza", и студент должен был показать, как эта строка будет представлена ​​в памяти на компьютере с прямым порядком байтов. Конечно, это звучит как вопрос с подвохом, потому что строки ASCII не подвержены проблемам с порядком байтов.

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

P-yM azzi

Я знаю, что это не может быть правильным. Ни на одной машине строка ASCII не может быть представлена ​​таким образом. Но, видимо, профессор настаивает на этом. Итак, я написал небольшую программу на C и сказал стажеру передать ее своему профессору.

#include <string.h>
#include <stdio.h>

int main()
{
    const char* s = "My-Pizza";
    size_t length = strlen(s);
    for (const char* it = s; it < s + length; ++it) {
        printf("%p : %c\n", it, *it);
    }
}

Это ясно демонстрирует, что строка хранится в памяти как «My-Pizza». Через день стажер возвращается ко мне и сообщает, что теперь профессор утверждает, что C автоматически преобразует адреса для отображения строки в правильном порядке.

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

Вот я и спрашиваю: кто здесь?


person Charles Salvia    schedule 14.10.2009    source источник
comment
У вас есть доступ к отладчику, чтобы показать проф? Это линукс или винда?   -  person Heath Hunnicutt    schedule 14.10.2009
comment
Конечно. То же самое можно продемонстрировать с помощью gdb в Linux, проверив каждый байт в памяти.   -  person Charles Salvia    schedule 14.10.2009
comment
Нет необходимости в отладчике: использование спецификатора формата %p в OP (хорошо сыгранное) говорит вам все, что вам действительно нужно знать.   -  person Chris Lutz    schedule 14.10.2009
comment
Хотя это strlen() в условном цикле for() заставляет меня съеживаться.   -  person Chris Lutz    schedule 14.10.2009
comment
ШУТКИ В СТОРОНУ? Кто это этот парень? (и +1 для Криса).   -  person Carl Norum    schedule 14.10.2009
comment
Г-н Лутц -- Зная о %p, я чувствовал, что этого профессору будет недостаточно. В конце концов, профессор уже чувствует, что оператор ++ делает что-то умное с char *, чтобы прыгать, он также может каким-то образом перенумеровать себя при передаче в printf(). Отладчик, являющийся еще одной реализацией и не зависящий от языка, я подумал, что он может обучить проф. ;)   -  person Heath Hunnicutt    schedule 15.10.2009
comment
Проверьте ассемблер и напишите свою собственную процедуру на ассемблере. Также... надеюсь никогда не встретить этого проф.   -  person Paul Nathan    schedule 15.10.2009
comment
Не думаю, что вы захотите назвать имя этого профессора.   -  person Crashworks    schedule 15.10.2009
comment
Хотя в этом вопросе это не имеет значения, я убрал вызов strlen из цикла, чтобы меньше людей писали так, приходя на собеседование.   -  person sharptooth    schedule 15.10.2009
comment
Возможно, я слишком доверяю профессионалу, но тот факт, что гуманизированное объяснение вывода никому не пришло в голову, заставляет меня думать, что SO действительно испортил ответ на этот вопрос...   -  person DigitalRoss    schedule 15.10.2009
comment
@Росс, я думаю, ты упускаешь суть; этот профессор по какой-то причине утверждает, что проблемы порядка следования байтов (которые по определению затрагивают только типы больше 8 бит) влияют на 8-битные данные. Можете ли вы объяснить, что, по вашему мнению, он пытается сказать?   -  person Carl Norum    schedule 15.10.2009
comment
Я просто привел пример в своем ответе. Конечно, я не могу читать мысли профессора, но тот факт, что это альтернативное объяснение даже не пришло людям в голову, вызывает озабоченность.   -  person DigitalRoss    schedule 15.10.2009
comment
Другое объяснение состоит в том, что и профессионалы, и толпа SO не совсем понимают это. Если профессор ошибается, вы, ребята, должны были по крайней мере понять, почему он мог ошибаться. Я все еще думаю, что это просто проблема репрезентации. Я думаю, нам нужно взять интервью у профессора, чтобы знать наверняка.   -  person DigitalRoss    schedule 15.10.2009
comment
$ cat › /tmp/pizza My-Pizza$ $ od -X /tmp/pizza 0000000 502d794d 617a7a69 0000010 $ Для протокола: y == 79, M == 4d. Вникнуть в суть?   -  person DigitalRoss    schedule 15.10.2009
comment
Да, я вижу это в вашем ответе ниже, но я не понимаю, как вы можете получить эту интерпретацию из вопроса. Мне кажется довольно ясным, что происходит. Если бы профессор был неправ и прояснил это вместо того, чтобы попытаться увековечить это своим ответом, который был сделан днем ​​позже, я думаю, это была бы другая история.   -  person Carl Norum    schedule 15.10.2009
comment
@Ross, вы смешиваете то, как строка может быть представлена ​​в определенном формате, по сравнению с тем, как она на самом деле хранится в памяти, в чем здесь проблема. По вашей логике испанский перевод строки также будет допустимым представлением, потому что это один из способов, которым конкретное приложение может интерпретировать строку.   -  person Charles Salvia    schedule 15.10.2009


Ответы (12)


Без сомнения, вы правы.

Стандарт ANSI C 6.1.4 указывает, что строковые литералы сохраняются в памяти путем «объединения» символов в литерале.

Стандарт ANSI 6.3.6 также определяет влияние добавления на значение указателя:

Когда выражение, имеющее целочисленный тип, добавляется к указателю или вычитается из него, результат имеет тип операнда указателя. Если операнд указателя указывает на элемент объекта массива, а массив достаточно велик, результат указывает на элемент, смещенный относительно исходного элемента, так что разница нижних индексов результирующего и исходного элементов массива равна интегральному выражению.

Если бы идея, приписываемая этому человеку, была верна, то компилятору также пришлось бы возиться с целочисленной математикой, когда целые числа используются в качестве индексов массива. Это также привело бы к множеству других заблуждений, которые оставляются воображению.

Человек может быть сбит с толку, потому что (в отличие от инициализатора строки) многобайтовые константы символов, такие как 'ABCD', хранятся в порядке следования байтов.

Есть много причин, по которым человек может запутаться в этом. Как предлагали здесь другие, он может неправильно читать то, что видит в окне отладчика, где содержимое было заменено байтами для удобочитаемости значений int.

person Heath Hunnicutt    schedule 14.10.2009
comment
Может быть, профессор смотрит в своем отладчике память в 32-битном режиме и смущается порядком байтов? - person Carl Norum; 14.10.2009
comment
Это всего лишь пробел в общении из-за того, что так мало людей видели настоящую свалку, и того факта, что никто здесь не признает, что вы должны печатать тысячу как 1000, а не 000,1. Этот совершенно неправильный ответ получил 8 голосов от одинаково сбитых с толку читателей... - person DigitalRoss; 15.10.2009
comment
@DigitalРосс. Послушай, Росс, мне не нравится твой комментарий. На данный момент я читаю дампы уже 29 лет. Мой ответ полностью правильный. Свидетельством этого факта является ваша неспособность обосновать какое-либо конкретное обратное. Или: пожалуйста, объясните сами. - person Heath Hunnicutt; 29.01.2013
comment
Путаница заключается в понимании порядка байтов в словах машины с прямым порядком байтов. Символы ASCII будут храниться в последовательных байтах, но в самой памяти байты физически упорядочены в обратном порядке. См. мой ответ для ссылок и изображений stackoverflow.com/a/14570771/922168 - person nickaknudson; 29.01.2013
comment
@Ник. Я подозреваю, что вы - голосование -1, которое поставило меня вчера в тупик. Ваш ответ - дезинформация. Очевидно, что просмотр дампа 32-битных слов на машине с прямым порядком байтов приведет к отображению изображения, похожего на то, о чем спрашивал OP. Это не то же самое, что спросил ОП. У нас нет никаких доказательств того, что профессор имел в виду это, на самом деле у нас есть доказательства ПРОТИВ: через день стажер возвращается ко мне и говорит, что теперь профессор утверждает, что C автоматически преобразует адреса для отображения строки. в надлежащем порядке. - person Heath Hunnicutt; 29.01.2013
comment
Все здесь уже знают, что просмотр последовательных байтовых данных в виде слов на машине с прямым порядком байтов покажет переставленные байты - это практически определение прямого порядка байтов. Утверждения о том, что OP относится к его профессору, касались не просмотра дампов в отладчике. По крайней мере, OP получил информацию о том, что претензия касается фактического порядка байтов в памяти. Довольно раздражает, что кабинетные психологи пытаются проникнуть в сознание профессора, критикуя правильные ответы, которых нет. Я думаю, что эти люди — рабы авторитетных фигур. - person Heath Hunnicutt; 29.01.2013

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

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

person AnT    schedule 14.10.2009
comment
Хорошо, @AndreyT, думаю, мне нужна твоя помощь. Вы, как обычно, правы, но может ли быть так: именно это и имел в виду проф? У меня такое чувство, что ТАКАЯ толпа качнулась в неправильном направлении на этом... - person DigitalRoss; 15.10.2009
comment
Хм... Может быть, но каков будет правильный ответ в этом случае? Если кто-то проверит память с прямым порядком байтов как последовательность байтов, он увидит там «My-Pizza». Если интерпретировать это как последовательность 2-байтовых целых чисел, это будет 'yM P-zi az'. В случае 4-байтовых целых это «P-yM azzi». И, наконец, 8-байтовая интерпретация int даст «azziP-yM». Все эти интерпретации — это просто интерпретации, способы отображения данных в памяти. Все они верны, если понять, откуда они взялись. Ничто не дает профессору оснований настаивать только на одном из них как на правильном. - person AnT; 15.10.2009
comment
Для отладчика очень мало смысла говорить, что это целое число, если оно хранится на машине с другим порядком байтов, будет представлять эту другую строку в памяти. - person caf; 16.10.2009
comment
Согласен с комментарием @AndreyT. Профессор должен был указать размер каждого слова. В данном случае профессор предположил 4-байтовое (32-битное) слово. - person nickaknudson; 29.01.2013

Endianness определяет порядок байтов в многобайтовых значениях. Строки символов представляют собой массивы однобайтовых значений. Таким образом, каждое значение (символ в строке) одинаково в архитектурах с прямым порядком байтов и обратным порядком байтов, и порядок следования байтов не влияет на порядок значений в структуре.

person Priyanshu Jain    schedule 05.05.2016

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

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

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

person Dmitry Brant    schedule 14.10.2009
comment
+1 Хит, я проделал много встроенной работы и никогда не видел ничего подобного. - person Carl Norum; 14.10.2009
comment
Один продукт, над которым я работал, использует DSP Texas Instruments (кажется, 2808), у которого наименьшая адресуемая единица памяти составляет 16 бит. - person Dmitry Brant; 14.10.2009
comment
Ага, все ставки сняты, когда дело доходит до DSP. Как бы вы написали программу OP только с 16-битной адресацией? Вам нужно самостоятельно разбивать 16-битные куски на 8-битные? - person Carl Norum; 14.10.2009
comment
Дмитрий, прикольно про DSP. Используете ли вы компилятор C с типом char *? Что происходит, когда у вас есть char * p = MyPi; и выполните i=*p; р++; дж=*р? Можете ли вы по отдельности адресовать байты, упакованные в 16-битные слова, с помощью char * в C? - person Heath Hunnicutt; 14.10.2009
comment
Символ в этом компиляторе на самом деле 16-битный. Таким образом, строка ASCII будет храниться с каждым символом, занимающим 16 бит, например M\0y\0-\0P\0.... Так что на самом деле то, что я написал в своем ответе, на практике не произойдет, по крайней мере для строковых литералов. Это происходит для длинных целых чисел; то есть 0x12345678 будет храниться как 0x3412 0x7856. - person Dmitry Brant; 15.10.2009
comment
Это больше похоже на то, что я ожидал от минимальной 16-битной адресации. - person Carl Norum; 15.10.2009
comment
Я тоже видел это, например, при программировании цифровой камеры Canon A620 с использованием хака CHDK. Мало того, что данные пикселей упакованы в 10 бит, доступ к данным осуществляется в 16-битном формате с обратным порядком байтов. Итак, вам нужно прочитать 2 символа, поменять их местами, повторить несколько раз и затем распаковать. - person rlbond; 15.10.2009
comment
Пожалуйста, перестаньте называть их байтами с более чем 8 битами... Вы говорите о размере слова процессора, а не о размере байта... ;) - person s1lence; 03.02.2012
comment
@ s1lence На самом деле, что касается стандарта C, байты не обязательно имеют ширину 8 бит. В разделе 3.6 проекта стандарта C99 байт определяется как: адресуемая единица хранения данных, достаточно большая, чтобы вместить любой элемент базового набора символов среды выполнения, а ее ширина в битах хранится в константе CHAR_BIT, которая должен быть больше или равен 8. Таким образом, если наименьшая адресуемая единица памяти этого DSP представляет собой 16-битное слово, в этой системе байт имеет ширину 16 бит. - person Lorenzo Donati -- Codidact.com; 12.05.2015

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

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 и окончательно определить отсутствие магии.

person caf    schedule 14.10.2009
comment
+1 за АСМ. Кроме того, вы можете написать эту подпрограмму на ассемблере только для того, чтобы доказать это. - person Paul Nathan; 15.10.2009
comment
+1 за сборку, я вернулся и связался с этим ответом из stackoverflow.com/questions/1565567/ - person sharptooth; 15.10.2009

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

P-yM azzi

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

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

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

Если профессор сказал, что порядок следования байтов машины влияет на то, как строки ascii будут представлены в памяти, ему нужно исправить свой поступок, кто-то должен его поправить.

Если бы вместо этого профессор привел пример того, как целые числа представляются/размещаются в машинах по-разному в зависимости от порядка байтов машины, его ученики могли бы оценить то, чему он учит.

person Michael Buen    schedule 15.10.2009

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

person Dinah    schedule 14.10.2009
comment
Учить кого-то чему-то, лгая, не означает учить чему-либо. Это ужасно, не позволяйте ему сойти с рук. - person Carl Norum; 14.10.2009

Вам может быть интересно, можно ли эмулировать архитектуру с прямым порядком байтов на машине с прямым порядком байтов или наоборот. Компилятор должен выдать код, который автоматически волшебным образом искажает младшие биты указателей char* всякий раз, когда он их разыменовывает: на 32-битной машине вы бы отображали 00 ‹-> 11 и 01 ‹-> 10.

Таким образом, если вы запишете число 0x01020304 на машине с обратным порядком байтов и прочитаете «первый» байт этого с помощью этого преобразования адреса, вы получите младший значащий байт, 0x04. Реализация C имеет обратный порядок байтов, хотя аппаратное обеспечение имеет обратный порядок байтов.

Вам нужен аналогичный трюк для коротких доступов. Невыровненный доступ (если поддерживается) может не относиться к соседним байтам. Вы также не можете использовать собственные хранилища для типов, больших, чем слово, потому что они будут казаться замененными словами при считывании по одному байту за раз.

Однако очевидно, что машины с прямым порядком байтов не делают этого постоянно, это очень специализированное требование, которое не позволяет вам использовать родной ABI. Мне кажется, что профессор думает о реальных числах как о «на самом деле» с обратным порядком байтов и глубоко смущен тем, что на самом деле представляет собой архитектура с прямым порядком байтов и/или как представлена ​​ее память.

Это правда, что строка "представлена ​​как" P-yM azzi на 32-битных l-e машинах, но только если под "представлением" вы подразумеваете "чтение слов представления в порядке возрастания адреса, но печать байтов каждого слова с обратным порядком байтов". Как уже говорили другие, это то, что могут делать некоторые представления памяти отладчика, так что это действительно a представление содержимого памяти. Но если вы собираетесь представлять отдельные байты, то более привычно перечислять их в порядке увеличения адреса, независимо от того, хранятся ли слова b-e или l-e, а не представлять каждое слово как многосимвольный литерал. Конечно, здесь не происходит никакого манипулирования указкой, и если выбранное профессором представление привело его к мысли, что оно существует, то оно ввело его в заблуждение.

person Steve Jessop    schedule 14.10.2009
comment
Что!? Назовите мне хоть один такой компилятор, который выдает эти автоматические коды, уничтожающие два нижних бита каждого доступа к указателю повсюду. - person Adam Rosenfield; 15.10.2009
comment
У меня есть специализированные библиотечные функции для этого в 1 из 10 миллионов случаев, это действительно правильно. - person Joshua; 15.10.2009
comment
@Adam: не строго компилятор, а так называемый транслятор, который вы можете рассматривать как серверную часть компилятора для ныне, к сожалению, несуществующей цели Tao Group. Среда намерений всегда была с прямым порядком байтов, даже на оборудовании с прямым порядком байтов. Это сделало реализацию сетевых драйверов немного запутанной, поскольку код намерения имел один порядок следования байтов, а встроенный нативный ассемблер — противоположный. И, как я специально сказал, он не искажал каждый доступ к указателю, он только искажал доступ к указателю не размером слова. Разработчикам портативных приложений стало проще тестировать их, потому что им не нужна была под рукой платформа b-e. - person Steve Jessop; 15.10.2009
comment
Однако более важная цель заключалась в том, что у намерения был виртуальный язык ассемблера и байтовый код, который для переносимости должен был иметь согласованный порядок следования байтов, согласованные размеры встроенных типов и т. д. Затем переводчик должен был заставить это работать на данной платформе. - person Steve Jessop; 15.10.2009

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

person Brian Postow    schedule 14.10.2009

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

person akif    schedule 15.10.2009

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

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

Для записи у == 79, М == 4d.

person DigitalRoss    schedule 15.10.2009
comment
Собственно, такой формат довольно стандартный. 32-битный дамп с ASCII в моем отладчике ARM показывает мне 32-битные слова в правильном (логическом) порядке, но дамп ASCII находится в байтовом порядке. - person Carl Norum; 15.10.2009
comment
Согласен, но это тоже моя точка зрения. Вам нужно было два дампа с противоположными парадигмами, напечатанные рядом. - person DigitalRoss; 15.10.2009
comment
Я должен добавить, что, конечно же, я не могу читать мысли профессора. Но я немного шокирован тем, что интерпретация, делающая точку зрения профессора абсолютно обоснованной, не пришла в голову многим людям. - person DigitalRoss; 15.10.2009
comment
Вероятно, потому, что совершенно нелепо использовать десятимильное запутанное объяснение для оправдания утверждения, которое все еще совершенно неверно. Вопрос заключался в том, находятся ли байты в памяти в таком порядке, и это не так. Тот факт, что они появятся задом наперед, если вы изо всех сил напечатаете их задом наперед, ничего не доказывает. - person hobbs; 15.10.2009
comment
Нет, эта идея пришла в голову Карлу Норуму за 5 часов до вашего поста. ОП сделал конкретное заявление: через день стажер возвращается ко мне и сообщает, что профессор теперь утверждает, что C автоматически преобразует адреса для отображения строки в правильном порядке. ОП, кажется, верит в стажера, который передает ему сообщение, но это, безусловно, может быть проблемой. Кроме того, ОП хочет знать, что правильно, и, похоже, ему нужны ссылки. Я согласен с вашим психоанализом в том, что это, вероятно, произошло из-за недопонимания, но отвечает ли это на вопрос ОП? - person Heath Hunnicutt; 15.10.2009
comment
Когда я говорю, что профессор запутался, я имею в виду, что он не прав, настаивая на одном и только одном способе представления как Единственно Верном, в то время как, как вы сами сказано выше, они оба правы. Более того, способов интерпретации содержимого памяти в этом случае больше. Теперь, в качестве дополнительного примечания, когда кто-то говорит о строках (последовательности байтов), попытка использовать 4-байтовое представление памяти int как единственный подходящий способ проверки памяти - это то, что я бы назвал неортодоксальным. - person AnT; 15.10.2009
comment
Откровенно говоря, не имеет значения, понимает ли проф порядок следования байтов или нет. Тот факт, что его студент ушел, задав конкретный вопрос, с впечатлением, что C автоматически конвертирует адреса, означает, что (по крайней мере, один из) студентов профессора не понимает порядка следования байтов. Тот, кто первым произнес слова «преобразование адресов», здесь не прав, потому что неправильно именно это. Одно дело спорить о том, как должна быть представлена ​​память с прямым порядком байтов, и, конечно, оба человека могут быть правы. Думать, что C меняет местами любые адреса, фактически неверно. - person Steve Jessop; 15.10.2009
comment
Послушайте, если предположить, что стажер, с которым я разговариваю, дает мне точные факты, профессор просто ошибается. Некоторые здесь утверждали, что профессор прав с определенной точки зрения, т.е. строка может быть представлена ​​как P-yM azzi, если вы используете отладчик и интерпретируете память как 32-битное целое число. Конечно, это правда, но это полностью вводит в заблуждение и не имеет никакого отношения к тому, как строка НА САМОМ ДЕЛЕ хранится в памяти. И, конечно же, совершенно неверно, что язык C выполняет какое-либо переназначение адресов под капотом, чтобы компенсировать порядок следования байтов. - person Charles Salvia; 15.10.2009
comment
Вы ошибаетесь в том, что это представление не имеет никакого отношения к тому, как строки фактически хранятся в памяти. Он описывает содержимое памяти отображением 1-1. Если профессор сказал, что для его курса именно так будет представлено содержимое памяти, то именно так будет представлена ​​рассматриваемая строка. Однако он не смог объяснить, что на самом деле происходит, что, по-видимому, является ошибкой на уроках. Он также ошибается, если думает, что это единственный способ описания памяти, точно так же, как вы ошибаетесь, говоря, что младшие байты адреса ДЕЙСТВИТЕЛЬНО слева. - person Steve Jessop; 15.10.2009
comment
Вам действительно нужно было опубликовать это как ответ И как комментарий? - person mrduclaw; 25.10.2009
comment
+1 (от нуля) за простое и простое объяснение того, что профессор, без сомнения, пытался сказать. Не уверен, почему это было так спорно. - person Bill Forster; 23.12.2009
comment
@DigitalRoss Я ожидаю, что вы ответите на мой комментарий, мистер 60 тысяч баллов из 1800 ответов... - person Heath Hunnicutt; 29.01.2013

Я столкнулся с этим и почувствовал необходимость прояснить это. Кажется, здесь никто не рассматривал концепцию bytes и words или как обратитесь к ним. байт состоит из 8 бит. слово – это набор байтов.

Если компьютер:

  • байт адресуемый
  • с 4-байтовыми (32-битными) словами
  • выровнено по словам
  • память просматривается "физически" (без дампа и перестановки байтов)

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

Порядок байтов в словах: (а) с прямым порядком байтов, (б) с прямым порядком байтов

Порядок байтов в словах: (a) Big Endian, (b) Little Endian

Символьные и целые данные в словах: (а) с обратным порядком байтов, (б) с прямым порядком байтов

Символьные и целочисленные данные в словах: (a) Big Endian, (b) Little Endian

Ссылки

person nickaknudson    schedule 28.01.2013
comment
вы написали, тогда действительно профессор был бы прав. И это абсолютно неверно. OP представил профессору (через стажера) некоторый код C, который вы, возможно, захотите изучить, пока не поймете его. А пока я вижу, что вы можете помогать людям, которые используют JavaScript и тому подобное. - person Heath Hunnicutt; 29.01.2013
comment
@Heath - код C будет иметь тот же результат, выполненный в Big Endian или Little Endian. Физическая диаграмма выше для прямого порядка байтов заставляет данные смотреть назад, но когда они переходят от возрастающего адреса байта, по одному байту за раз, они будут печататься в одном и том же порядке в любой системе и приводить к My-Pizza. Профессор архитектуры хотел, чтобы он отображался как вторая диаграмма выше для Little Endian. Это очень распространенный тип вопросов на уроках компьютерной архитектуры. Это правильный ответ, и я соглашусь с тем, что опубликованный Intel документ является правильным в этом вопросе. - person axawire; 16.06.2013
comment
@axawire - нет никаких сомнений в отношении документа Intel или других известных представлений в адресе слова (например, команды DD в отладчике). Возникает вопрос: как эти правильные представления связаны с неправильным представлением, данным OP? Ответ психологический: это попытки разобраться в бессмыслице, представленной в вопросе. Сами по себе они аксиоматичны в своей правильности. Что касается ответа на вопрос ОП, они ошибаются. Чтобы ответить в этих терминах; неправильный. Притвориться, что я подвергаю сомнению условность: соломенный человек. Добрый день, аксавир. - person Heath Hunnicutt; 16.06.2013
comment
@HeathHunnicutt, когда я был студентом, это был самый полезный ответ. Это может быть неправильно из-за используемых вами соглашений, но это помогает мне понять, что происходит на аппаратном уровне. - person whossname; 27.07.2015
comment
@user2161613 user2161613 понимаете ли вы, что строка ASCII хранится в памяти один символ за другим без замены байтов? Потому что это факт. Этот ответ, несмотря на всю его изящную графику, в основном неверен. Если память просматривать физически, символы будут в порядке. - person Heath Hunnicutt; 27.07.2015
comment
@HeathHunnicutt, да, сегодня я снова работал над этим, и ты прав. Этот ответ сбивает с толку. Лучшее объяснение, которое я видел до сих пор, — это просто игра с симулятором MARS MIPS. Подходит ли простая версия с прямым порядком байтов для чисел, а с прямым порядком байтов для строк? Под правым видом я подразумеваю, что сначала в MSF появятся числа, а строки появятся так, как если бы вы читали слева направо. - person whossname; 30.07.2015
comment
Я думаю, что это был ответ, который я искал electronics.stackexchange.com/questions/1760/ - person whossname; 01.08.2015