gug-bg-herd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kazehakase]: FTBFS под GNU/Hurd: mozilla.cpp:132: error: 'PATH_MAX'


From: Dimitur Kirov
Subject: Re: [kazehakase]: FTBFS под GNU/Hurd: mozilla.cpp:132: error: 'PATH_MAX' was not declared in this scope
Date: Fri, 21 Aug 2009 16:38:05 +0000

Yavor Doganov <address@hidden> wrote:
> Нали в Си (надявам се и C++) всеки низ съхраняван в (указател на) char
> по конвенция завършва с \0?  Или нещо не съм разбрал...
Програмистите се грижат за това да се слага \0 след края на низа. Няма
такова нещо като автоматично зануляване. Ако xpcomPath е непроменен от
GRE_GetGREPathWithProperties тогава xpcomPath ще съдържа произволна
последователност от символи (заради g_malloc, вместо g_malloc0)

В случай, че xpcomPath е непроменена, имаме два възможни грешни случая:

 1. може в тaзи последователност от байтове да няма \0
Тогава strlen излиза извън заделената памет и дава възможност за
пробив, или забивка
 2. ако случайно има \0 байт на произволно място, то проверката 
'if (strlen(xpcomPath) < allocated -1)' ще е истина и функцията ще
продължи изпълнението си, сякаш xpcomPath е правилно инициализиран, а
той реално не е

> > ако GRE_GetGREPathWithProperties не е променила xpcomPath тогава
> 
> Възможна ли е тази ситуация?  На мен ми се струва, че не е.
Ако се стигне до ред 213 от този код, ситуацията е точно такава -
aBuffer, аргументът който отговаря на xpcomPath е непроменен

http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsGREGlue.cpp#213


> Великите модзиладжии ползват MAXPATHLEN в имплементацията на тази
> функция (и най-вероятно на много други места), което обяснява защо
> няма xulrunner на тази платформа.  Което пък означава, че кръпката за
> Kz не е особено необходима поне засега :-).

 да са живи и здрави :-)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]