From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20085 invoked by alias); 20 Feb 2010 04:31:43 -0000 Received: (qmail 20077 invoked by uid 22791); 20 Feb 2010 04:31:42 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL X-Spam-Check-By: sourceware.org Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com) (71.74.56.123) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 20 Feb 2010 04:31:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=6V0dr_hT2w8A:10 a=VceORaAXMj-0KuzTCDAA:9 a=uL3xn-cwfW-dBdm7PQoA:7 a=drK3tssPoc2ahvDmMC6i5trUSEEA:4 Received: from [24.174.61.131] ([24.174.61.131:45281] helo=[192.168.1.4]) by hrndva-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id BF/15-01313-7A56F7B4; Sat, 20 Feb 2010 04:31:35 +0000 Message-ID: <4B7F65A6.7050000@cs.utexas.edu> Date: Sat, 20 Feb 2010 04:31:00 -0000 From: "Field G. Van Zee" User-Agent: Thunderbird 2.0.0.23 (X11/20091012) MIME-Version: 1.0 To: Brian Gough CC: gsl-discuss mailing list , Rhys Ulerich , jungman@lanl.gov Subject: Re: Feedback from GSL folks on libflame 4.0 References: <4a00655d1002171047t4e87fb85w88b609245e3f9a8e@mail.gmail.com> <4B7D90B5.4020707@cs.utexas.edu> <87wry9ovy6.wl%bjg@network-theory.co.uk> In-Reply-To: <87wry9ovy6.wl%bjg@network-theory.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2010-q1/txt/msg00041.txt.bz2 Brian, Thanks for the suggestion. I'm preparing to leave for SIAM 2010, but once I get back I will look into implementing some changes to the error-checking in libflame. We may have to go Gerard's route and have dual interfaces, or we might do it as you propose. Error checking right now in libflame is a bit of an organized hack, and so I'll need to sit down and look at just how much code will need to be updated to implement any changes. As always, we appreciate your input! Field Brian Gough wrote: >> It seemed like a better idea to just get our attention so we could >> fix the problem. We agree that using return values would be a more >> standard way of handling errors, but we're also somewhat cynical in >> that we don't trust our users to check return values. > > The approach in GSL is to have an abort() by default, for the same > reason. But the user can turn off the abort() and use the error > return values instead by providing an alternative error handler as a > function pointer. Here's how it would look with your functions: > > === FLA_macro_defs.h === > > // Error code translation and output macro definition. > #define FLA_Check_error_code( code ) \ > do { \ > if (code != FLA_SUCCESS) { \ > FLA_Check_error_code_helper( code, __FILE__, __LINE__ ); \ > return code; \ /* see comment below about void functions */ > } \ > } while (0) > > > === FLA_main_prototypes.h === > > typedef void FLA_error_handler_t (int code, const char * file, int line); > > > === FLA_Check.c === > > static FLA_error_handler_t * FLA_error_handler = NULL; > > void FLA_Check_error_code_helper( int code, char* file, int line ) > { > if ( code == FLA_SUCCESS ) > return; > > if (FLA_error_handler) > { > (*FLA_error_handler) (code, file, line); > return ; > } > > if ( FLA_ERROR_CODE_MAX <= code && code <= FLA_ERROR_CODE_MIN ) > { > FLA_Print_message( FLA_Error_string_for_code( code ), > file, line ); > FLA_Abort(); > } > else > { > FLA_Print_message( FLA_Error_string_for_code( FLA_UNDEFINED_ERROR_CODE ), > file, line ); > FLA_Abort(); > } > } > > > (We actually have three macro GSL_ERROR, GSL_ERROR_VOID and > GSL_ERROR_VAL to handle different types of return value - error code, > void, and "other". This is to avoid warnings about "returning a value > from a void function" etc).