Кстати, я тоже не помню происхождения файла...
Это выдержки из compilerFpcKOLComObj.pas, которого нет на SVN, а когда я прокачивал последний раз Compiler_fpc.exe - уже тоже и не вспомню...

Имею, и очень настырно.
Причем, когда конструктор (StringToOleStr) находится у нутре компилятора, а деструктор (SysFreeString) находится у нутре оси - это уже беспредел в квадрате
Грешить, ИМХО, логичнее на этот беспредел, а не на глючность FPC
((Ну может еще на то, что никсоиды, в отличие от дяденьки Бормана, тоже тупо нулик всегда предпочитают лепить))

Слушай, ну ты посмотри то, чего в ImageLoader (и что сейчас я воткнул в KOLEdb)
И скажи свое мнение.
Вопрос-то действительно серьезный, и я действительно не умею тестировать KOLEdb

Философский аспект этой проблемы я понимаю так (в cpp-шном изложении)
Существует два подхода:

создать объект какого-то класса через new, и вернуть указатель на этот объект

не создавать объект, а иметь типом результата ссылку на этот объект
Первый случай, это то, что мы видим, и упираемся в тупики типа "А как тогда иначе вернуть строку?", когда даже уничтожать нечего (имени-то нет у результата), а по логике - надо бы.
Во втором случае, объект создается вызывающей ф-ей (невидимая локальная переменная) и его адрес передается как дополнительный аргумент.
При выходе из зоны видимости этой невидимой локальной переменной - она уничтожается (с вызовом деструктора) автоматически.
Это в cpp - так, он это обязан делать (насколько я понимаю) с любым типом.
А в дельфях этот второй фокус делается только со своими, особо любимыми типами
К которым относится String, wideString...
Тут уж я не виноват...
------------ Дoбавленo:

tsdima писал(а):

Может _Р_ и должно быть 3, но у меня никакой константы нет, а тупо стоит ноль.

На это я тебе вот чего скажу:
В ImageLoader кодовая страничка выделена как отдельный аргумент для StringToWideString, и вызывается с тройкой
Так вот, если подставить нулики, то, не раз упомянутый Ведмедь.jpg - не читается
А с тройкой - легко