> The pthreads that you pointed out were just a slip up. They are now fixed.
Thanks for your quick response. > For the fputs and sendit, when it applies to tty output are not worth > checking > the error codes. Do you care for failed output and log messages? > 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. This is the general problem with exceptional situations. http://accu.org/index.php/journals/546 You do not need to make assumptions about error situations. Please check all error codes. Otherwise, it might not be noticed if anything unexpected went wrong. > If we fix all such occurrences, Bacula would be extremely bloated. I have got a different opinion on this issue. I would prefer to improve the software on correctness and robustness. > 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 imagine that it is not needed to distinguish on the "importance" in this way if tools from the technology of aspect-oriented programming can be automatically applied. > smartalloc is a critical component of Bacula. My intent was not to criticise your memory allocator implementation (malloc alternative). I am more concerned about the constructor functions in your class library and the avoidance of some C++ new operator uses. > 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. Would you like to support software environments which do not depend on an out of memory killer? ;-) > 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. I have got the impression that the source files do not use the full power of C++ yet. Did you consider to implement your own new operator for the Bacula class library already? > 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. It seems that you still apply a traditional C coding style to big parts of the source code. Would you like to benefit from code that will be automatically generated for you? How many instructions and work can be saved by different means? Regards, Markus ------------------------------------------------------------------------------ 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
