From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gsl-discuss-return-5630-listarch-gsl-discuss=sources.redhat.com@sourceware.org>
Received: (qmail 31673 invoked by alias); 19 Feb 2010 20:07:09 -0000
Received: (qmail 31665 invoked by uid 22791); 19 Feb 2010 20:07:08 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0
	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Feb 2010 20:07:04 +0000
Date: Fri, 19 Feb 2010 20:07:00 -0000
Message-ID: <87wry9ovy6.wl%bjg@network-theory.co.uk>
From: Brian Gough <bjg@gnu.org>
To: "Field G. Van Zee" <field@cs.utexas.edu>
Cc: gsl-discuss mailing list <gsl-discuss@sourceware.org>,
	Rhys Ulerich <rhys.ulerich@gmail.com>,
	jungman@lanl.gov
Subject: Re: Feedback from GSL folks on libflame 4.0
In-Reply-To: <4B7D90B5.4020707@cs.utexas.edu>
References: <4a00655d1002171047t4e87fb85w88b609245e3f9a8e@mail.gmail.com>
	<4B7D90B5.4020707@cs.utexas.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Message-Mac: 321ebd113bdab08feed080a597299f8a
Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gsl-discuss.sourceware.org>
List-Subscribe: <mailto:gsl-discuss-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gsl-discuss/>
List-Post: <mailto:gsl-discuss@sourceware.org>
List-Help: <mailto:gsl-discuss-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gsl-discuss-owner@sourceware.org
X-SW-Source: 2010-q1/txt/msg00034.txt.bz2

> 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).