Исходное сообщение
"Первый стабильный релиз компоновщика Mold, развиваемого разр..." Отправлено n00by, 19-Дек-21 10:26
>> Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу. > В таком случае вызывающий get_realpath() должен деаллоцировать результат с помощью free(). Да. Точно так же в Си++ будет деаллоцирован буфер std:string. Только в Си все освобождения явны. > А что если get_realpath() вернёт не результат realpath(), a path, полученный > параметром? Он то вообще непонятно где находится и как аллоцирован. Тогда > мы имеем или double free, или попытку сделать free() на указатель > на стеке. С сопутствующими проблемами безопасности. Значит нельзя просто возвращать path, > а надо сделать ему strdup(), получается одно копирование заменили на другое. > Ты можешь сказать, ну тогда надо менять всю функцию, чтоб копирования > не было. Или вообще её убрать и те 2-4 строчки в > вызывающий код вписать. Ну да, в Си эта обёртка вроде как совсем не нужна. > Но тогда можно и на С++ тоже функцию > полностью переписать "по правильному". И вообще теряется весь предмет разговора. Так и я о том. Вроде как переписали на Си++, но наполовину, в итоге там потенциально буфер переполняется. >> Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата? > Да, запросто. В общем, непонятна экономия. Если есть имя файла, значит его будут читать, а это всю "оптимизацию" с кучей перевесит.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: