и каким, по-вашему, оно должно быть?

Ясень пень, - оно должно соответствовать платформе!
Для винды одно для юникса другое.

фиксировать в стандарте, какой чертик на конце строки должен сидеть, имхо - не то время!

а сам форт должен воспринимать оба конца строки одинаково.
В крайнем случае, 0D0A принимать как две строки. Хотя, экономить на этом смысла нету.

можно еще извернуться - завести в словаре слово с именем в один байт 0D - которое будет заканчивать трансляцию строки. И считать концом строки байт 0А. Но это явный изврат.

вопрос понят не правильно.
под представлением строк понимается то:
- как они хранятся в памяти, (AsciiZ, Pascal, др.)
- какой может быть максимальная длина строки
- как хранить unicode строки
и прочие подобные вопросы.

упс...

я сделал бы так
разделил бы строки с разным представлением символов.
для байтовых - строки двух типов - строка со счетчиком или asciiz одна в другую конвертится легким перемещением строки на 1 байт с удалением байта-счетчика в начале и записью нуля в освободившееся место на конце.
Аналогично для строк с двух(четырех)байтовыми символами - только счетчик у них 2(4)-хбайтовый и нуль тоже.

А строка - без начала (счетчика) и конца(нуля) - строкой не считается, а считается массивом или блоком данных.

максимальная длина строки, соответственно, для байтовых 255, для словных - 65534, для 4-хбайтовых - 4Gb

6 вариантов строк - многовато - но что имеем то и имеем.
Зарывать голову в песок или выбирать на все случаи жизни одно представление смысла нету.

Так и хранятся - ASCIIZ, Pascal, др.

Какая указана в документации на систему. Как вариант - какая хранится в системной константе.

В Unicode.

Еще одно предложение:
строка с условным счетчиком переменной длины:



Первый байт получается старший, но это вряд ли должно смущать.

Можно еще признак zip-сжатия строки втюхать в первый байт, если хочется экономии на спичках.
Или добавить признак размера символа.

Это уже получаются не столько строки, сколько блоки данных. Думается, над строками должны быть выстроены операции, а уж как строка хранится - второй вопрос. И в любом случае, не имеет смысла делать размер счетчика больше, чем размер адреса в системе. Впрочем, можно еще так.



А то и так



xxxx - размер символа в байтах (1-16)
yyyy - длина счетчика в байтах (1-16)

Строка "на всякий случай" завершается нулем, чтобы быть еще и ASCIIZ.

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

вот, почему-то кажется, что от 0 до 15. 0 байт длины - значит 2⁰=1 - чисто односимвольная строка.

Может, оно и смешно, но получается еще и просто кодировка символа вида
xxxx 0000 код-символа где xxxx - размер символа в байтах.
Можно в xxxx закодировать даже не размер, а тип кодировки: - dos866 win1251, КОИ, UTFxx
и т.д. и т.п.

использовать восемь представлений строк по моему не менее накладно чем одно универсальное
ну и плюс не побоюсь быть побитым но понятие "строка" в данном случае не строка из файла,
а просто выделенная область память с данными
а что там в реале, строка из Пушкина, или полностью стихотворение или бинарник прочтенный из
файла -- не суть важно, поэтому строка со счетчиком без альтернативна вопрос лишь в организации
оного, отдельнае ли переменная в для "двухзначное переменной" или первые n байт в "строке"
вариант со счетчиком переменной длины
(по моему первый раз здесь предложенный mOleg в другой ветке)
это подходящий компромис для тех кто стремится экономить каждый байт и тех кто желает
оперировать метровыми "строками" со свободным содержанием,
вот только предусматреть сразу с расчетом на будущее, (время то бежит фиг догонишь)
не ограниченость счетчика, ну тоесть чтоб через пару тройку лет не вставал вапрос как мне
оперировать терробайтной строкой, или через еще пару лет "теромегабайтной" фоткой со свадьбы ...
ну вот примерно так имхо маё на это смотрит
ну и конечно в своем стремлении к универсальности кодировку уникодную я выбираю... по возможности,
а так CP866 использую

я хочу только заметить, что согласно АНС94 над счетчиком строки позволительно производить операцию C@ и С! , что приводит к неприятному, на мой взгляд, последствию - нельзя менять формат строки. У меня в форке строки представлены различным образом (от опций сборки зависит) и анси тест идет только при условии, что длина счетчика строки будет созразмерна С@ , который в реальности B@. Поэтому, мне кажется, что даже добавление ряда слов для поддержания стандарта не будет результативным по целому ряду причин.
То есть обратная совместимость не очень-то и нужна.

неужели история с майкрософтом и обратной совместимостью ничему не учит?

ну и к чему это?