Imported from libpng-1.0.7beta17.tar

contrib/visupng/cexcept.h

@@ -0,0 +1,244 @@
+/*===
+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 */