Упс, а эврики-то на работе у меня и нет

Но я подозреваю, что дополнение буфера символом #0 посреди строки вполне может
сносить крышу самой эврике (видит, что идёт обращение к строке после "символа конца строки в сишном синтаксисе" — хотя вроде не должно быть таких идиотских глюков)
Либо утечка есть в дальнейшей работе с буфером , эврика видит, что косяк растёт из указанных строчек и ругается на них.

На D7 без эврики:

  while true do 
  begin
    s:='';
    GetRandomName(s,10,false);
    Form1.Caption:=s;
  end

За 10 минут память кушать не начал...
хм... Может всё-таки эврика?

M>Здравствуйте, <Аноним>, Вы писали:

А>>Добрый день, подскажите пожалуйста, где тут утечка происходит, через каждые два три запуска данной процедуры, EurekaLog жалуется на не освобожденную память..

А>>procedure GetRandomName(var Buffer: String; StrLen: Integer; const Hex: Boolean = False);
А>>const
А>> FillMap1 = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890';
А>> FillMap2 = '0123456789ABCDEF';
А>>var
А>> i: Integer;
А>>begin
А>> Randomize;
M>генератор я бы инициализировал где-нибудь в onCreate, т.к. смыл получается не совсем "RandomName" — при каждом вызове начинаем заново.

А>> for i:=1 to StrLen do
А>> if (Hex) then
А>> Buffer:=Buffer + FillMap2[Random(Length(FillMap2)+1)+1] else // Жалуется на эти
А>> Buffer:=Buffer + FillMap1[Random(Length(FillMap1)+1)+1]; // 2 строки в зависимости от Hex=true или false.
M>В адресации массивов FillMap* непонятные операции (если это не хитрая часть алгоритма). Так (для FillMap2, например):
M>Length=16
M>0<=Random(16+1)<=16
M>и индекс [Random(16+1)+1] лежит в диапазоне 1..17, а вот элемента №17 в строке как-то уже и нету — должен вылететь Access Violation по идее.
А>>end;

M>А с памятью — ну кроме адресации несуществующего элемента, вроде не вижу ничего. Сейчас D7 докачается из дома — попробую прогнать...
А>>Помогите разобраться, в чем тут дело..



M>-- С уважением...