contrib/visupng/cexcept.h - third_party/libpng - Git at Google

 /*===
 cexcept.h 1.0.0 (2000-Jun-21-Wed)
 Adam M. Costello <amc@cs.berkeley.edu>

 An interface for exception-handling in ANSI C, developed jointly with
 Cosmin Truta <cosmin@cs.toronto.edu>.

     Copyright (c) 2000 Adam M. Costello and Cosmin Truta.  Everyone
     is hereby granted permission to do whatever they like with this
     file, provided that if they modify it they take reasonable steps to
     avoid confusing or misleading people about the authors, version,
     and terms of use of the derived file.  The copyright holders make
     no guarantees about the correctness of this file, and are not
     responsible for any damage resulting from its use.

 If this interface is used by multiple .c files, they shouldn't include
 this header file directly.  Instead, create a wrapper header file that
 includes this header file and then invokes the define_exception_type
 macro (see below), and let your .c files include that header file.

 The interface consists of one type, one well-known name, and six macros.


 define_exception_type(type_name);

     This macro is used like an external declaration.  It specifies
     the type of object that gets copied from the exception thrower to
     the exception catcher.  The type_name can be any type that can be
     assigned to, that is, a non-constant arithmetic type, struct, union,
     or pointer.  Examples:

         define_exception_type(int);

         enum exception { out_of_memory, bad_arguments, disk_full };
         define_exception_type(enum exception);

         struct exception { int code; const char *msg; };
         define_exception_type(struct exception);


 struct exception_context;

     This type may be used after the define_exception_type() macro has
     been invoked.  A struct exception_context must be known to both
     the thrower and the catcher.  It is expected that there be one
     context for each thread that uses exceptions.  It would certainly
     be dangerous for multiple threads to access the same context.
     One thread can use multiple contexts, but that is likely to be
     confusing and not typically useful.  The application can allocate
     this structure in any way it pleases--automatic, static, or dynamic.
     The application programmer should pretend not to know the structure
     members, which are subject to change.


 struct exception_context *the_exception_context;

     The Try/Catch and Throw statements (described below) implicitly
     refer to a context, using the name the_exception_context.  It is
     the application's responsibility to make sure that this name yields
     the address of a mutable (non-constant) struct exception_context
     wherever those statements are used.  Subject to that constraint, the
     application may declare a variable of this name anywhere it likes
     (inside a function, in a parameter list, or externally), and may
     use whatever storage class specifiers (static, extern, etc) or type
     qualifiers (const, volatile) it likes.  Examples:

         static struct exception_context
           * const the_exception_context = &foo;

         { struct exception_context *the_exception_context = bar; ... }

         int blah(struct exception_context *the_exception_context, ...);

         extern struct exception_context the_exception_context[1];

     The last example illustrates a trick that avoids creating a pointer
     object separate from the structure object.

     The name could even be a macro, for example:

         struct exception_context ec_array[numthreads];
         #define the_exception_context (ec_array + thread_id)

     Be aware that the_exception_context is used several times by the
     Try/Catch/Throw macros, so it shouldn't be expensive or have side
     effects.  The expansion must be a drop-in replacement for an
     identifier, so it's safest to put parentheses around it.


 void init_exception_context(struct exception_context *ec);

     For context structures allocated statically (by an external
     definition or using the "static" keyword), the implicit
     initialization to all zeros is sufficient, but contexts allocated
     by other means must be initialized using this macro before they
     are used by a Try/Catch statement.  It does no harm to initialize
     a context more than once (by using this macro on a statically
     allocated context, or using this macro twice on the same context),
     but a context must not be re-initialized after it has been used by a
     Try/Catch statement.


 Try statement
 Catch (expression) statement

     The Try/Catch/Throw macros are capitalized in order to avoid
     confusion with the C++ keywords, which have subtly different
     semantics.

     A Try/Catch statement has a syntax similar to an if/else
     statement, except that the parenthesized expression goes after
     the second keyword rather than the first.  As with if/else,
     there are two clauses, each of which may be a simple statement
     ending with a semicolon or a brace-enclosed compound statement.
     But whereas the else clause is optional, the Catch clause is
     required.  The expression must be a modifiable lvalue (something
     capable of being assigned to) of the exact same type passed to
     define_exception_type().

     If a Throw that uses the same exception context as the Try/Catch is
     executed within the Try clause (typically within a function called
     by the Try clause), and the exception is not caught by a nested
     Try/Catch statement, then a copy of the exception will be assigned
     to the expression, and control will jump to the Catch clause.  If no
     such Throw is executed, then the assignment is not performed, and
     the Catch clause is not executed.

     Regardless of whether an exception is caught, the expression is
     always evaluated exactly once, which is significant if it has side
     effects, for example:

         Try foo();
         Catch (p[++i].e) { ... }

     IMPORTANT: Jumping into or out of a Try clause (for example via
     return, break, continue, goto, longjmp) is forbidden--the compiler
     will not complain, but bad things will happen at run-time.  Jumping
     into or out of a Catch clause is okay, and so is jumping around
     inside a Try clause.  In many cases where one is tempted to return
     from a Try clause, it will suffice to use Throw, and then return
     from the Catch clause.  Another option is to set a flag variable and
     use goto to jump to the end of the Try clause, then check the flag
     after the Try/Catch statement.

     IMPORTANT: The values of any non-volatile automatic variables
     changed within the Try clause are undefined after an exception is
     caught.  Therefore, variables modified inside the Try block whose
     values are needed later outside the Try block must either use static
     storage or be declared with the "volatile" type qualifier.


 Throw expression;

     A Throw statement is very much like a return statement, except that
     the expression is required.  Whereas return jumps back to the place
     where the current function was called, Throw jumps back to the Catch
     clause of the innermost enclosing Try clause.  The expression must
     be compatible with the type passed to define_exception_type().  The
     exception must be caught, otherwise the program may crash.

     Slight limitation:  If the expression is a comma-expression it must
     be enclosed in parentheses.


 Try statement
 Catch_anonymous statement

     When the value of the exception is not needed, a Try/Catch statement
     can use Catch_anonymous instead of Catch (expression).


 Everything below this point is for the benefit of the compiler.  The
 application programmer should pretend not to know any of it, because it
 is subject to change.

 ===*/


 #ifndef CEXCEPT_H
 #define CEXCEPT_H


 #include <setjmp.h>

 #define define_exception_type(etype) \
 struct exception__state { \
   etype *exception; \
   jmp_buf env; \
 }

 struct exception_context { \
   struct exception__state *last; \
   int caught; \
 };

 #define init_exception_context(ec) ((void)((ec)->last = 0))

 #define Catch(e) exception__catch(&(e))
 #define Catch_anonymous exception__catch(0)

 #define Try \
   { \
     struct exception__state *exception__p, exception__s; \
     int exception__i; \
     exception__p = the_exception_context->last; \
     the_exception_context->last = &exception__s; \
     for (exception__i = 0; ; exception__i = 1) \
       if (exception__i) { \
         if (setjmp(exception__s.env) == 0) { \
           if (&exception__s)

 #define exception__catch(e_addr) \
           else { } \
           the_exception_context->caught = 0; \
         } \
         else the_exception_context->caught = 1; \
         the_exception_context->last = exception__p; \
         break; \
       } \
       else exception__s.exception = e_addr; \
   } \
   if (!the_exception_context->caught) { } \
   else

 /* Try ends with if(), and Catch begins and ends with else.  This     */
 /* ensures that the Try/Catch syntax is really the same as the        */
 /* if/else syntax.                                                    */
 /*                                                                    */
 /* We use &exception__s instead of 1 to appease compilers that        */
 /* warn about constant expressions inside if().  Most compilers       */
 /* should still recognize that &exception__s is never zero and avoid  */
 /* generating test code.                                              */
 /*                                                                    */
 /* We use the variable exception__i to start the loop at the bottom,  */
 /* rather than jump into the loop using a switch statement, to        */
 /* appease compilers that warn about jumping into loops.              */

 #define Throw \
   for (;; longjmp(the_exception_context->last->env, 1)) \
     if (the_exception_context->last->exception) \
       *the_exception_context->last->exception =


 #endif /* CEXCEPT_H */
	/*===
	cexcept.h 1.0.0 (2000-Jun-21-Wed)
	Adam M. Costello <amc@cs.berkeley.edu>

	An interface for exception-handling in ANSI C, developed jointly with
	Cosmin Truta <cosmin@cs.toronto.edu>.

	Copyright (c) 2000 Adam M. Costello and Cosmin Truta. Everyone
	is hereby granted permission to do whatever they like with this
	file, provided that if they modify it they take reasonable steps to
	avoid confusing or misleading people about the authors, version,
	and terms of use of the derived file. The copyright holders make
	no guarantees about the correctness of this file, and are not
	responsible for any damage resulting from its use.

	If this interface is used by multiple .c files, they shouldn't include
	this header file directly. Instead, create a wrapper header file that
	includes this header file and then invokes the define_exception_type
	macro (see below), and let your .c files include that header file.

	The interface consists of one type, one well-known name, and six macros.


	define_exception_type(type_name);

	This macro is used like an external declaration. It specifies
	the type of object that gets copied from the exception thrower to
	the exception catcher. The type_name can be any type that can be
	assigned to, that is, a non-constant arithmetic type, struct, union,
	or pointer. Examples:

	define_exception_type(int);

	enum exception { out_of_memory, bad_arguments, disk_full };
	define_exception_type(enum exception);

	struct exception { int code; const char *msg; };
	define_exception_type(struct exception);


	struct exception_context;

	This type may be used after the define_exception_type() macro has
	been invoked. A struct exception_context must be known to both
	the thrower and the catcher. It is expected that there be one
	context for each thread that uses exceptions. It would certainly
	be dangerous for multiple threads to access the same context.
	One thread can use multiple contexts, but that is likely to be
	confusing and not typically useful. The application can allocate
	this structure in any way it pleases--automatic, static, or dynamic.
	The application programmer should pretend not to know the structure
	members, which are subject to change.


	struct exception_context *the_exception_context;

	The Try/Catch and Throw statements (described below) implicitly
	refer to a context, using the name the_exception_context. It is
	the application's responsibility to make sure that this name yields
	the address of a mutable (non-constant) struct exception_context
	wherever those statements are used. Subject to that constraint, the
	application may declare a variable of this name anywhere it likes
	(inside a function, in a parameter list, or externally), and may
	use whatever storage class specifiers (static, extern, etc) or type
	qualifiers (const, volatile) it likes. Examples:

	static struct exception_context
	* const the_exception_context = &foo;

	{ struct exception_context *the_exception_context = bar; ... }

	int blah(struct exception_context *the_exception_context, ...);

	extern struct exception_context the_exception_context[1];

	The last example illustrates a trick that avoids creating a pointer
	object separate from the structure object.

	The name could even be a macro, for example:

	struct exception_context ec_array[numthreads];
	#define the_exception_context (ec_array + thread_id)

	Be aware that the_exception_context is used several times by the
	Try/Catch/Throw macros, so it shouldn't be expensive or have side
	effects. The expansion must be a drop-in replacement for an
	identifier, so it's safest to put parentheses around it.


	void init_exception_context(struct exception_context *ec);

	For context structures allocated statically (by an external
	definition or using the "static" keyword), the implicit
	initialization to all zeros is sufficient, but contexts allocated
	by other means must be initialized using this macro before they
	are used by a Try/Catch statement. It does no harm to initialize
	a context more than once (by using this macro on a statically
	allocated context, or using this macro twice on the same context),
	but a context must not be re-initialized after it has been used by a
	Try/Catch statement.


	Try statement
	Catch (expression) statement

	The Try/Catch/Throw macros are capitalized in order to avoid
	confusion with the C++ keywords, which have subtly different
	semantics.

	A Try/Catch statement has a syntax similar to an if/else
	statement, except that the parenthesized expression goes after
	the second keyword rather than the first. As with if/else,
	there are two clauses, each of which may be a simple statement
	ending with a semicolon or a brace-enclosed compound statement.
	But whereas the else clause is optional, the Catch clause is
	required. The expression must be a modifiable lvalue (something
	capable of being assigned to) of the exact same type passed to
	define_exception_type().

	If a Throw that uses the same exception context as the Try/Catch is
	executed within the Try clause (typically within a function called
	by the Try clause), and the exception is not caught by a nested
	Try/Catch statement, then a copy of the exception will be assigned
	to the expression, and control will jump to the Catch clause. If no
	such Throw is executed, then the assignment is not performed, and
	the Catch clause is not executed.

	Regardless of whether an exception is caught, the expression is
	always evaluated exactly once, which is significant if it has side
	effects, for example:

	Try foo();
	Catch (p[++i].e) { ... }

	IMPORTANT: Jumping into or out of a Try clause (for example via
	return, break, continue, goto, longjmp) is forbidden--the compiler
	will not complain, but bad things will happen at run-time. Jumping
	into or out of a Catch clause is okay, and so is jumping around
	inside a Try clause. In many cases where one is tempted to return
	from a Try clause, it will suffice to use Throw, and then return
	from the Catch clause. Another option is to set a flag variable and
	use goto to jump to the end of the Try clause, then check the flag
	after the Try/Catch statement.

	IMPORTANT: The values of any non-volatile automatic variables
	changed within the Try clause are undefined after an exception is
	caught. Therefore, variables modified inside the Try block whose
	values are needed later outside the Try block must either use static
	storage or be declared with the "volatile" type qualifier.


	Throw expression;

	A Throw statement is very much like a return statement, except that
	the expression is required. Whereas return jumps back to the place
	where the current function was called, Throw jumps back to the Catch
	clause of the innermost enclosing Try clause. The expression must
	be compatible with the type passed to define_exception_type(). The
	exception must be caught, otherwise the program may crash.

	Slight limitation: If the expression is a comma-expression it must
	be enclosed in parentheses.


	Try statement
	Catch_anonymous statement

	When the value of the exception is not needed, a Try/Catch statement
	can use Catch_anonymous instead of Catch (expression).


	Everything below this point is for the benefit of the compiler. The
	application programmer should pretend not to know any of it, because it
	is subject to change.

	===*/


	#ifndef CEXCEPT_H
	#define CEXCEPT_H


	#include <setjmp.h>

	#define define_exception_type(etype) \
	struct exception__state { \
	etype *exception; \
	jmp_buf env; \
	}

	struct exception_context { \
	struct exception__state *last; \
	int caught; \
	};

	#define init_exception_context(ec) ((void)((ec)->last = 0))

	#define Catch(e) exception__catch(&(e))
	#define Catch_anonymous exception__catch(0)

	#define Try \
	{ \
	struct exception__state *exception__p, exception__s; \
	int exception__i; \
	exception__p = the_exception_context->last; \
	the_exception_context->last = &exception__s; \
	for (exception__i = 0; ; exception__i = 1) \
	if (exception__i) { \
	if (setjmp(exception__s.env) == 0) { \
	if (&exception__s)

	#define exception__catch(e_addr) \
	else { } \
	the_exception_context->caught = 0; \
	} \
	else the_exception_context->caught = 1; \
	the_exception_context->last = exception__p; \
	break; \
	} \
	else exception__s.exception = e_addr; \
	} \
	if (!the_exception_context->caught) { } \
	else

	/* Try ends with if(), and Catch begins and ends with else. This */
	/* ensures that the Try/Catch syntax is really the same as the */
	/* if/else syntax. */
	/* */
	/* We use &exception__s instead of 1 to appease compilers that */
	/* warn about constant expressions inside if(). Most compilers */
	/* should still recognize that &exception__s is never zero and avoid */
	/* generating test code. */
	/* */
	/* We use the variable exception__i to start the loop at the bottom, */
	/* rather than jump into the loop using a switch statement, to */
	/* appease compilers that warn about jumping into loops. */

	#define Throw \
	for (;; longjmp(the_exception_context->last->env, 1)) \
	if (the_exception_context->last->exception) \
	*the_exception_context->last->exception =


	#endif /* CEXCEPT_H */