diff options
Diffstat (limited to 'contrib/visupng/cexcept.h')
| -rw-r--r-- | contrib/visupng/cexcept.h | 243 |
1 files changed, 0 insertions, 243 deletions
diff --git a/contrib/visupng/cexcept.h b/contrib/visupng/cexcept.h deleted file mode 100644 index dbea51e..0000000 --- a/contrib/visupng/cexcept.h +++ /dev/null @@ -1,243 +0,0 @@ -/*=== -cexcept.h 2.0.0 (2001-Jul-12-Thu) -Adam M. Costello <amc@cs.berkeley.edu> - -An interface for exception-handling in ANSI C (C89 and subsequent ISO -standards), developed jointly with Cosmin Truta <cosmin@cs.toronto.edu>. - - Copyright (c) 2001 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 regarding this file, and are not responsible for any - damage resulting from its use. - -Only user-defined exceptions are supported, not "real" exceptions like -division by zero or memory segmentation violations. - -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); - - Because throwing an exception causes the object to be copied (not - just once, but twice), programmers may wish to consider size when - choosing the exception type. - - -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, etc) 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 same type (disregarding type qualifiers) that - was 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. - - The expression is not evaluated unless and until the exception is - caught, 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_context { \ - jmp_buf *penv; \ - int caught; \ - volatile struct { etype etmp; } v; \ -} - -/* etmp must be volatile because the application might use automatic */ -/* storage for the_exception_context, and etmp is modified between */ -/* the calls to setjmp() and longjmp(). A wrapper struct is used to */ -/* avoid warnings about a duplicate volatile qualifier in case etype */ -/* already includes it. */ - -#define init_exception_context(ec) ((void)((ec)->penv = 0)) - -#define Try \ - { \ - jmp_buf *exception__prev, exception__env; \ - exception__prev = the_exception_context->penv; \ - the_exception_context->penv = &exception__env; \ - if (setjmp(exception__env) == 0) { \ - if (&exception__prev) - -#define exception__catch(action) \ - else { } \ - the_exception_context->caught = 0; \ - } \ - else { \ - the_exception_context->caught = 1; \ - } \ - the_exception_context->penv = exception__prev; \ - } \ - if (!the_exception_context->caught || action) { } \ - else - -#define Catch(e) exception__catch(((e) = the_exception_context->v.etmp, 0)) -#define Catch_anonymous exception__catch(0) - -/* 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__prev instead of 1 to appease compilers that */ -/* warn about constant expressions inside if(). Most compilers */ -/* should still recognize that &exception__prev is never zero and */ -/* avoid generating test code. */ - -#define Throw \ - for (;; longjmp(*the_exception_context->penv, 1)) \ - the_exception_context->v.etmp = - - -#endif /* CEXCEPT_H */ |