-#include <xbt/misc.h>
-#include <xbt/sysdep.h>
-
-/* required ISO-C standard facilities */
-#include <stdio.h>
-
-/* the machine context */
-#if defined(__EX_MCTX_MCSC__)
-#include <ucontext.h> /* POSIX.1 ucontext(3) */
-#define __ex_mctx_struct ucontext_t uc;
-#define __ex_mctx_save(mctx) (getcontext(&(mctx)->uc) == 0)
-#define __ex_mctx_restored(mctx) /* noop */
-#define __ex_mctx_restore(mctx) (void)setcontext(&(mctx)->uc)
-
-#elif defined(__EX_MCTX_SSJLJ__)
-#include <setjmp.h> /* POSIX.1 sigjmp_buf(3) */
-#define __ex_mctx_struct sigjmp_buf jb;
-#define __ex_mctx_save(mctx) (sigsetjmp((mctx)->jb, 1) == 0)
-#define __ex_mctx_restored(mctx) /* noop */
-#define __ex_mctx_restore(mctx) (void)siglongjmp((mctx)->jb, 1)
-
-#elif defined(__EX_MCTX_SJLJ__) || !defined(__EX_MCTX_CUSTOM__)
-#include <setjmp.h> /* ISO-C jmp_buf(3) */
-#define __ex_mctx_struct jmp_buf jb;
-#define __ex_mctx_save(mctx) (setjmp((mctx)->jb) == 0)
-#define __ex_mctx_restored(mctx) /* noop */
-#define __ex_mctx_restore(mctx) (void)longjmp((mctx)->jb, 1)
-#endif
-
-/* declare the machine context type */
-typedef struct { __ex_mctx_struct } __ex_mctx_t;
-
-/** \ingroup XBT_ex
- *
- * This module is a small ISO-C++ style exception handling library
- * for use in the ISO-C language. It allows you to use the paradigm
- * of throwing and catching exceptions in order to reduce the amount
- * of error handling code without hindering program robustness.
- *
- * This is achieved by directly transferring exceptional return codes
- * (and the program control flow) from the location where the exception
- * is raised (throw point) to the location where it is handled (catch
- * point) -- usually from a deeply nested sub-routine to a parent
- * routine. All intermediate routines no longer have to make sure that
- * the exceptional return codes from sub-routines are correctly passed
- * back to the parent.
- *
- * These features are brought to you by a modified version of the libex
- * library, one of the numerous masterpiece of Ralf S. Engelschall.
- *
- * @section Introduction
- *
- * In SimGrid, exceptions is a triple <\a msg , \a category , \a value>
- * where \a msg is a human-readable text describing the exceptional
- * condition, \a code an integer describing what went wrong and \a value
- * providing a sort of sub-category. (this is different in the original libex).
- *
- * @section Basic usage
- *
- * \em xbt_try \b TRIED_BLOCK [\em xbt_cleanup \b CLEANUP_BLOCK] \em xbt_catch (variable) \b CATCH_BLOCK
- *
- * This is the primary syntactical construct provided. It is modeled after the
- * ISO-C++ try-catch clause and should sound familiar to most of you.
- *
- * Any exception thrown directly from the TRIED_BLOCK block or from called
- * subroutines is caught. Cleanups which must be done after this block
- * (whenever an exception arised or not) should be placed into the optionnal
- * CLEANUP_BLOCK. The code dealing with the exceptions when they arise should
- * be placed into the (mandatory) CATCH_BLOCK.
- *
- *
- * In absence of exception, the control flow goes into the blocks TRIED_BLOCK
- * and CLEANUP_BLOCK (if present); The CATCH_BLOCK block is then ignored.
- *
- * When an exception is thrown, the control flow goes through the following
- * blocks: TRIED_BLOCK (up to the statement throwing the exception),
- * CLEANUP_BLOCK (if any) and CATCH_BLOCK. The exception is stored in a
- * variable for inspection inside the CATCH_BLOCK. This variable must be
- * declared in the outter scope, but its value is only valid within the
- * CATCH_BLOCK block.
- *
- * Some notes:
- * - xbt_try, xbt_cleanup and xbt_catch cannot be used separately, they work
- * only in combination and form a language clause as a whole.
- * - In contrast to the syntax of other languages (such as C++ or Jave) there
- * is only one xbt_catch block and not multiple ones (all exceptions are
- * of the same C type xbt_t).
- * - the variable of xbt_catch can naturally be reused in subsequent
- * xbt_catch clauses.
- * - it is possible to nest xbt_try clauses.
- *
- * The xbt_try block is a regular ISO-C language statement block, but it is not
- * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
- * "return", "goto" or longjmp(3) because there is some hidden setup and
- * cleanup that needs to be done regardless of whether an exception is
- * caught. Bypassing these steps will break the exception handling facility.
- *
- * The xbt_cleanup and xbt_catch blocks are regular ISO-C language statement
- * blocks without any restrictions. You are even allowed to throw (and in the
- * xbt_catch block to re-throw) exceptions.
- *
- * There is one subtle detail you should remember about xbt_try blocks:
- * Variables used in the xbt_cleanup or xbt_catch clauses must be declared with
- * the storage class "volatile", otherwise they might contain outdated
- * information if an exception it thrown.
- *
- *
- * This is because you usually do not know which commands in the xbt_try
- * were already successful before the exception was thrown (logically speaking)
- * and because the underlying ISO-C setjmp(3) facility applies those
- * restrictions (technically speaking). As a matter of fact, value changes
- * between the xbt_try and the xbt_throw may be discarded if you forget the
- * "volatile" keyword.
- *
- * @section Advanced usage
- *
- * @subsection xbt_defer DEFERING_BLOCK
- *
- * This directive executes DEFERING_BLOCK while deferring the throwing of
- * exceptions, i.e., exceptions thrown within this block are remembered, but
- * the control flow still continues until the end of the block. At its end, the
- * first exception which occured within the block (if any) is rethrown (any
- * subsequent exceptions are ignored).
- *
- * DEFERING_BLOCK is a regular ISO-C language statement block, but it is not
- * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
- * "return", "goto" or longjmp(3). It is however allowed to nest xbt_defer
- * clauses.
- *
- * @subsection xbt_shield SHIELDED_BLOCK
- *
- * This directive executes SHIELDED_BLOCK while shielding it against the
- * throwing of exceptions, i.e., any exception thrown from this block or its
- * subroutines are silently ignored.
- *
- * SHIELDED_BLOCK is a regular ISO-C language statement block, but it is not
- * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
- * "return", "goto" or longjmp(3). It is however allowed to nest xbt_shield
- * clauses.
- *
- * @subsection Retrieving the current execution condition
- *
- * \a xbt_catching, \a xbt_deferred and \a xbt_shielding return a boolean
- * indicating whether the current scope is within a TRYIED_BLOCK,
- * DEFERING_BLOCK and SHIELDED_BLOCK (respectively)
- *
- * \section PROGRAMMING PITFALLS
- *
- * Exception handling is a very elegant and efficient way of dealing with
- * exceptional situation. Nevertheless it requires additional discipline in
- * programming and there are a few pitfalls one must be aware of. Look the
- * following code which shows some pitfalls and contains many errors (assuming
- * a mallocex() function which throws an exception if malloc(3) fails):
- *
- \verbatim
-// BAD EXAMPLE
-xbt_try {
- char *cp1, *cp2, cp3;