-#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__) || defined(__EX_MAYDAY)
-#include <setjmp.h> /* ISO-C jmp_buf(3) */
-#define __ex_mctx_struct jmp_buf jb;
-#define __ex_mctx_save(mctx) ( MAYDAY_SAVE(mctx) setjmp((mctx)->jb) == 0)
-#define __ex_mctx_restored(mctx) /* noop */
-#define __ex_mctx_restore(mctx) ( MAYDAY_RESTORE(mctx) (void)longjmp((mctx)->jb, 1))
-#endif
-/* declare the machine context type */
-typedef struct {
-__ex_mctx_struct} __ex_mctx_t;
-
-/** @addtogroup XBT_ex
- * @brief A set of macros providing exception a la C++ in ANSI C (grounding feature)
- *
- * 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.
- *
- * \htmlonly <div class="toc">\endhtmlonly
- *
- * @section XBT_ex_toc TABLE OF CONTENTS
- *
- * - \ref XBT_ex_intro
- * - \ref XBT_ex_base
- * - \ref XBT_ex_pitfalls
- *
- * \htmlonly </div> \endhtmlonly
- *
- * @section XBT_ex_intro DESCRIPTION
- *
- * In SimGrid, an exception 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 XBT_ex_base BASIC USAGE
- *
- * \em TRY \b TRIED_BLOCK [\em TRY_CLEANUP \b CLEANUP_BLOCK] \em 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 arose 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:
- * - TRY, CLEANUP and 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 CATCH block and not multiple ones (all exceptions are
- * of the same \em xbt_ex_t C type).
- * - the variable of CATCH can naturally be reused in subsequent
- * CATCH clauses.
- * - it is possible to nest TRY clauses.
- *
- * The TRY block is a regular ISO-C language statement block, but
- *
- * <center><b>it is not
- * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
- * "return", "goto" or longjmp(3)</b>.</center>
- *
- * This is 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 symptom are likely to be a segfault at the next exception raising point,
- * ie far away from the point where you did the mistake. Finding the problem can
- * reveal challenging, unfortunately.
- *
- * The CLEANUP and CATCH blocks are regular ISO-C language statement
- * blocks without any restrictions. You are even allowed to throw (and, in the
- * CATCH block, to re-throw) exceptions.
- *
- * There is one subtle detail you should remember about TRY blocks:
- * Variables used in the CLEANUP or CATCH clauses must be declared with
- * the storage class "volatile", otherwise they might contain outdated
- * information if an exception is thrown.
- *
- *
- * This is because you usually do not know which commands in the 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 TRY and the THROW may be discarded if you forget the
- * "volatile" keyword.
- *
- * \section XBT_ex_pitfalls 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):
- *
- * \dontinclude ex.c
- * \skip BAD_EXAMPLE
- * \until end_of_bad_example
- *
- * This example raises a few issues:
- * -# \b variable \b scope \n
- * Variables which are used in the CLEANUP or CATCH clauses must be
- * declared before the TRY clause, otherwise they only exist inside the
- * TRY block. In the example above, cp1, cp2 and cp3 only exist in the
- * TRY block and are invisible from the CLEANUP and CATCH
- * blocks.
- * -# \b variable \b initialization \n
- * Variables which are used in the CLEANUP or CATCH clauses must
- * be initialized before the point of the first possible THROW is
- * reached. In the example above, CLEANUP would have trouble using cp3
- * if mallocex() throws a exception when allocating a TOOBIG buffer.
- * -# \b volatile \b variable \n
- * Variables which are used in the CLEANUP or CATCH clauses MUST BE
- * DECLARED AS "volatile", otherwise they might contain outdated
- * information when an exception is thrown.
- * -# \b clean \b before \b catch \n
- * The CLEANUP clause is not only place before the CATCH clause in
- * the source code, it also occures before in the control flow. So,
- * resources being cleaned up cannot be used in the CATCH block. In the
- * example, c3 gets freed before the printf placed in CATCH.
- * -# \b variable \b uninitialization \n
- * If resources are passed out of the scope of the
- * TRY/CLEANUP/CATCH construct, they naturally shouldn't get
- * cleaned up. The example above does free(3) cp1 in CLEANUP although
- * its value was affected to globalcontext->first, invalidating this
- * pointer.
-
- * The following is fixed version of the code (annotated with the pitfall items
- * for reference):
- *
- * \skip GOOD_EXAMPLE
- * \until end_of_good_example
- *
- * @{
- */
