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: Sat, 22 Aug 2009 23:44:32 +0300

> Димитър Киров wrote:
> > За да не се налага да препрочитаме всяка една междинна функция, или
> > да стискаме палци тя да не се променя, най-добре е в горния пример
> > g_malloc -> g_malloc0
> 
> Разбрах защо трябва да се ползва g_malloc0; благодаря за обясненията.
> 
> Ако GRE_GetGREPathWithProperties не промени xpcomPath и върне грешка
> (NS_ERROR_FILE_NAME_TOO_LONG или каквото и да е), strlen (xpcomPath)
> ще е 0, т.е. ще се излезе от цикъла.  След това NS_FAILED(rv) ще е
> истина, и xulrunner_init ще върне FALSE.  Абсолютно същото поведение е
> и в момента, без кръпката.
+1

само трябва да се оправи и мястото на етиката out, за да може функцията
да връща TRUE все някога

Ако някой програмист, вманиачен на тема производителност ти се заяде за
g_malloc0, че уж работела по-бавно (което е съмнително), тогава може да
направиш:

xpcomPath = g_malloc (allocated);
xpcomPath[0] = '\0';

така при NS_ERROR_FILE_NAME_TOO_LONG резулатът от strlen ще е 0 и се
получава пак излизане от цикъла и връщане на FALSE

Още нещо (предполагам, че го знаеш ама все пак)....
Когато използваш glib-ския allocator е добре да стартираш програмата с
променливи на средата G_DEBUG и G_SLICE 

примерно:
$ G_DEBUG=gc-friendly G_SLICE=always-malloc ./kazehakase

така паметта се заделя/освобождава на момента и много грешки свързани с
нея лъсват веднага.




reply via email to

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