On Tue, Jan 08, 2008 at 05:06:17PM +0100, Klaus Kaempf wrote:

* Michael Schroeder [Jan 08. 2008 17:03]:

...

On Tue, Jan 08, 2008 at 05:00:15PM +0100, Klaus Kaempf wrote:

...

The current sat-solver implementation (solver.c) has almost 30 (thirty !) calls to abort(). Since C does not support exceptions, these calls should be replaced by proper return values.

These are no exceptions, but assertions. It makes no sense to return something.

Then please use assert().

Ok, will do. M. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Tue, Jan 08, Michael Schroeder wrote:

On Tue, Jan 08, 2008 at 05:06:17PM +0100, Klaus Kaempf wrote:

...

* Michael Schroeder [Jan 08. 2008 17:03]:

...

On Tue, Jan 08, 2008 at 05:00:15PM +0100, Klaus Kaempf wrote:

...

The current sat-solver implementation (solver.c) has almost 30 (thirty !) calls to abort(). Since C does not support exceptions, these calls should be replaced by proper return values.

These are no exceptions, but assertions. It makes no sense to return something.

Then please use assert().

Ok, will do.

IMO not acceptable for the solver lib to call abort (explicit or via assert). Please return some errorcode and let the applicatin handle it. (and don't write to stdout/stderr) #define SATTHROW( RET ) \ do { \ POOL_DEBUG( SAT_ERROR, "%s(%s):(%d) -> error %d\n", \ __FILE__, __FUNCTION__, __LINE, RET ); \ return RET; \ } while ( 0 ) -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

* Michael Schroeder [Jan 08. 2008 18:07]:

No, if an assertion fails it normally means data corruption. It really makes no sense to return something in that case. Even glibc aborts in that case.

Well ... I partly agree and I partly disagree ;-) My current problem with sat-solver, and why I stumbled over the aborts, is reusablitity of the 'Solver' structure. It seems that it cannot be used multiple times because some internal queues aren't properly re-initialized. The current way of simply aborting without giving a reason or even a line number is just not acceptable (imho). (The actual error also shows missing test coverage for the case in question.) I do agree that in case of data corruption, 'drastic means' have to be taken. But please not without some 'last words' ;-) Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org