X-Git-Url: https://git.pterodactylus.net/?a=blobdiff_plain;f=gtkmm-osx%2Flibpng-1.2.5%2Fcontrib%2Fvisupng%2Fcexcept.h;fp=gtkmm-osx%2Flibpng-1.2.5%2Fcontrib%2Fvisupng%2Fcexcept.h;h=532b23dae469ca25100eaa545707ceb89b644d4e;hb=a095981e18cc37a8ecc7cd237cc22b9c10329264;hp=0000000000000000000000000000000000000000;hpb=9459638ad6797b8139f1e9f0715c96076dbf0890;p=synfig.git diff --git a/gtkmm-osx/libpng-1.2.5/contrib/visupng/cexcept.h b/gtkmm-osx/libpng-1.2.5/contrib/visupng/cexcept.h new file mode 100644 index 0000000..532b23d --- /dev/null +++ b/gtkmm-osx/libpng-1.2.5/contrib/visupng/cexcept.h @@ -0,0 +1,244 @@ +/*=== +cexcept.h 1.0.0 (2000-Jun-21-Wed) +Adam M. Costello + +An interface for exception-handling in ANSI C, developed jointly with +Cosmin Truta . + + 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 + +#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 */