On Monday 16 November 2009 17:25:42 SF Markus Elfring wrote: > Hello, > > I pointed out that return values from various function calls were ignored > at some places in the source files. http://bugs.bacula.org/view.php?id=1405
The pthreads that you pointed out were just a slip up. They are now fixed. For the fputs and sendit, when it applies to tty output are not worth checking the error codes. It requires a lot of code and it is not clear how to recover from such situations. I feel it is simply better to continue. If we fix all such occurrences, Bacula would be extremely bloated. Where there are error codes that are important (such as pthreads) ignored, we should fix them. > > I suggested a few design choices. Which ways are acceptable to fix the > involved details? The design choice is to not worry about some unlikely errors providing it is not important. In important cases for proper functioning of Bacula we should check. > > I would like to continue the discussion with the mentioned memory > allocator. > http://bacula.org/3.0.x-manuals/en/developers/developers/Smart_Memory_Alloc >ation.html smartalloc is a critical component of Bacula. It does everything that glibc does (and since 2000), and ensures that we have a program that does not lose memory. In addition, it detects frees of non-allocated memory, double frees, and buffer corruptions. The code is somewhat old and could use a bit of cleanup. For example, I would prefer to use the dlist() class for chaining the buffers together rather than the b_queue code, but that is not anything critical. Since it is such a fundamental part of Bacula, it will be very difficult to make any changes to it, because doing so will surely destabilize it and create bugs. This code has been working without a single failure for almost 10 years now (within Bacula) and an additional 12 years prior to Bacula. > > I see the requirement that all users of a malloc compatible API should > generally deal with handling of null pointers. In Bacula malloc() cannot return a NULL. It blows up Bacula if there is no memory, so there is no need for any Bacula call to malloc() to check if there is a a NULL pointer. > I find it strange that the > C++ new operator is not used for this purpose in your class library. > http://bacula.git.sourceforge.net/git/gitweb.cgi?p=bacula/bacula;a=blob;f=b >acula/src/lib/bsock.c;h=a2e3bb275c47f9fa63ec0a7bb0f6df04b8f49459;hb=HEAD#l55 I am opposed to using new. We very seldom use it, and in some places we use New(), but as soon as I have some time, I will remove all them. Using new has many disadvantages, mainly that it does not check for corrupted buffers as our version of malloc() does. We much prefer to use: ptr = new_dlist(); and constructs like that, and in the new_dlist(), it explicitly calls malloc. This makes the code simple and clean -- the compiler is not generating hidden code. In addition, except in a few limited places we do not use automatic class definition that allocate memory. (one place is the POOLMEM class). When the compiler allocates memory without the programmer explicitly writing the memory allocation call, it is a receipe for sloppy programming where either you lose memory buffers (orphaned buffers) or you do many more mallocs than necessary. A large part of Bacula uses Pooled memory which allows automatic increasing of buffer size and reduces system calls. By the way, I received your FLA today -- thanks. Best regards, Kern ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
