diff options
Diffstat (limited to 'runtime/libpng/contrib/visupng/cexcept.h')
| -rw-r--r-- | runtime/libpng/contrib/visupng/cexcept.h | 244 |
1 files changed, 0 insertions, 244 deletions
diff --git a/runtime/libpng/contrib/visupng/cexcept.h b/runtime/libpng/contrib/visupng/cexcept.h deleted file mode 100644 index 532b23d..0000000 --- a/runtime/libpng/contrib/visupng/cexcept.h +++ /dev/null @@ -1,244 +0,0 @@ -/*=== -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 */ |