Re: [kazehakase]: FTBFS под GNU/Hurd: mozilla.cpp:132: error: 'PATH_MAX' was not declared in this scope

[Dimitur Kirov]

> но твърдението,
> че strlen очаква '\0' в низа не е вярно.
точно така е по документация и реализация.
Няма друг начин, по който strlen да разбере къде свършва низа.

В много случаи може да се окаже че следващият байт е \0 без да си се
старал да го заделиш и инициализираш на ръка. Това става например,
когато паметта не е много използвана (в началото на програмата). Друг
такъв пример е когато се използват частни алокатори, като SLUB в glib.
При SLUB винаги се заделя малко повече памет наведнъж, за да не се губи
време в многократно заделяне на малки сегменти.
При SLUB g_malloc0(3) би заделил първоначално примерно 128 байта с \0
Програмата от предните постове ще работи, защото на 4-то място винаги ще
има \0. Но произволна по-голяма програма ще се счупи в случай, че
паметта е интензивно използвана и се стигне до момента, в който
раболагаме само с 3 свободни байта. Много рядко, но напълно възможно.
Възможно е на даден компютър, или на дадена версия на glib този
алокатор въобще да го няма.

Липсата на \0 си е грешка в кода на програмата, независимо дали тази
грешка води винаги до счупване, или само в редки случаи.

> За избягването на strlen не съм убеден
не съм казал да не се ползва напълно, а да се ползва само, когато сме
сигурни, че в низа има \0

> 
> Ако съжденията ти са верни, то кръпката за PA е недъгава (както и
> много други подобни).  Нали така?
да, но с една условност:

xpcomPath = g_malloc(x);
some_function (xpcomPath);
strlen (xpcomPath)

ако знаем, че 'some_function' не винаги променя xpcomPath, или още
по-точно - не винаги записва \0 в него, то тогава това е bug.

Ако сме сигурни, че some_function винаги записва \0 в xpcomPath, то
тогава не е bug.

За да не се налага да препрочитаме всяка една междинна функция, или да
стискаме палци тя да не се променя, най-добре е в горния пример
g_malloc -> g_malloc0