Странная ошибка при обработке строки

[Didim]

GunSmoker, в MessageBox нормально отображалось содержимое строки. Ошибок не возникало. MessageBox использовался для поиска этой ошибки.

Если s: string;
s:='Блаблабла';
MessageBox(0, pchar(s),'000',0);
Какая тут проблема?

"Код целиком" - весь лист. Эти переменные - уровня модуля.

Кстати, string тоже оканчивается нулём.

[GunSmoker]

Чёрным по белому написал, что при ss[i] используется больше данных, чем при PChar(ss). Откуда следует, что если с ss[i] проблема, а с PChar(ss) проблемы нет, то причина сидит в этой разнице.

[Didim]

GunSmoker, что Вы хотите сказать? Неправильно использовался MessageBox, или не допустимо добавление rst:=rst+ss[l]?

Следует из этой ошибки. Строка ss содержит символы, но символы недоступны как ss[l];
Чтобы вопросов не было, добавлю:
l - больше нуля, и меньше длины строки..

[GunSmoker]

Почитайте вот это: http://www.transl-gunsmoker.ru/2009/09/pchars.html и вот это: http://docwiki.embarcadero.com/RADSt...g_String_Types

Я не знаю, как ещё объяснить.

Неправильно использовался MessageBox, или не допустимо добавление rst:=rst+ss[l]?

Я первым же сообщением сказал, что в том коде, который приведён, проблемы нет. Проблема сидит в том коде, который вы не показали.

[Didim]

GunSmoker, ошибка возникает именно в этом месте. Перед возникновением ошибки (т.е., до rst:=rst+ss[l]) строка ss проверяется, и имеет длину 16 символов. Строку можно даже посмотреть: она существует... Как это вдруг ss[l] и даже ss[l-4] моментально оказывается нулевым адресом??? Это происходит в начале цикла, на первом же заходе!

Если бы ошибка была в другом месте, строка уже была бы нулевой.

Какая может быть проблема, кроме библиотечной?

Pchar не имеет никакого отношения к этой ошибке. Преобразование делалось только для MessageBox. Но стока проверялась и length... А появляется она из ReadLn(fr1,ss).

[GunSmoker]

Перед возникновением ошибки (т.е., до rst:=rst+ss[l]) строка ss проверяется, и имеет длину 16 символов. Строку можно даже посмотреть: она существует...

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

На словах получается что ты контролируешь проблему проблемными же средствами (у тебя "не работает" строка и ты проверяешь её же строковыми функциями). Это примерно как доказать самому себе, что ты не сошёл с ума. Бесполезное занятие.

Какая может быть проблема, кроме библиотечной?

Сначала проверь свой код, а потом уже вини других.

Вот простой пример:

procedure TForm1.Button1Click(Sender: TObject);
var
  S: array [0..1] of Integer;
  I: Integer;
begin
  I := 2;           // предположим, что это значение как-то вычисляется и
                    // из-за ошибки в программе получает неверное значение
  S[I] := 0;        // эта строка затрёт адрес возврата из Button1Click в стеке
end;                // в этой строке произойдёт Access Violation, т.к. мы испортили адрес возврата

Запусти этот код. Получишь AV. Это "ошибка библиотеки"? Нет, это наши кривые руки.

Обрати внимание, что AV возникает не в месте проблемы (I := 2), а далеко от неё (на end). Так же и у тебя: В ПРИВЕДЁННОМ ТОБОЙ КОДЕ С SS НЕТ ОШИБОК!!!

Сколько раз ещё нужно это сказать, чтобы дошло?

Если не понятно. Автомобиль врезался в дерево. Ты можешь сколько угодно искать проблему в этом дереве, но исходная проблема сидит в другом месте (водитель пьян, неисправные тормоза, превышение скорости, кошка на дороге и т.п.).

Так доступнее?

P.S. Чтобы не было недоразумений: я не говорю, что у тебя в точности эта проблема, что в примере. Это был пример не связанности места возникновения AV с его причиной.

[Didim]

GunSmoker, не бесполезное. Все ошибки так отлавливаются. Тут выясняется, что до этой операции строка имеет нормальное состояние, и не нулевой адрес. Ошибка, которую Вы приводите в пример, была бы сразу обнаружена.

Посмотрите на приведённый код! Длина строки на входе в процедуру проверяется length, которое и даёт значение l. А while проверяет, что l>0. Т.е., l находится в пределах длины строки!

Ваши варианты того, что может быть со строкой такого, что обращение к ss[l] вызывает ошибку...

А я думаю о том, что при этой операции запрашивается память для увеличения длины принимающей строки...

[Camaro Chevelle]

Ребятки, ну что вы спорите...
может, мой совет очень туп и бесполезен, но может попробовать объявить такое

var
  z: array[0..sizeof(ss)-1] of byte absolute ss

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

я совсем ничего не понимаю

[GunSmoker]

Я сейчас головой об стол буду стучать.

В приведённом коде ошибок НЕТ.

Ваше упорство по скрытию кода достойно лучшего применения.

Ваши варианты того, что может быть со строкой такого, что обращение к ss[l] вызывает ошибку...

Эти варианты можно перечислять бесконечно. Начнём, пожалуй, со вспышек на Солнце... сильно легче стало?

P.S.

Все ошибки так отлавливаются.

Вовсе нет.

В данном случае, если ты действительно хочешь "выяснить, что до этой операции (какой?) строка имеет нормальное состояние, и не нулевой адрес", то открой CPU отладчик. И посмотри, чем "до" отличается от "после".

[GunSmoker]

Ребятки, ну что вы спорите...

Я не спорю, я пытаюсь клещами вытянуть из автора вопроса его код.