--- /dev/null
+/*===
+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 */
projects / synfig.git / blobdiff