On Monday 16 November 2009 19:00:34 SF Markus Elfring wrote: > > 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?
I don't understand. > > > 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. Bacula is one of the most correct and robust programs I have ever seen. > > > 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. I don't understand. > > > 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. We have a small set of C++ constructs that we use, and we don't want any new operator uses. See the Developer's Guide for more details. > > > 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 don't understand. > > > 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 do not want to use the full power of C++. We are already happy with our small subset. It is robust and very portable. > > > 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. Yes, that is exactly what we do. Bacula is C code with a few selected C++ features. We don't want any more. > Would you like to benefit from code that will be > automatically generated for you? No. > How many instructions and work can be saved by different means? Sorry, but many of your questions I just don't understand -- such as the above one. I suppose they are retorical? As I say, we are ready to improve the code, but only within certain limits, and whatever we do must be done in a conservative way so as not to introduce errors. 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
