+#include <stdio.h> /* snprintf */
+#include <stdlib.h> /* snprintf */
+
+#include "portable.h" /* to get a working stdarg.h */
+
+#include "xbt_modinter.h"
+
+#include "xbt/misc.h"
+#include "xbt/ex.h"
+#include "xbt/str.h"
+#include "xbt/sysdep.h"
+#include "xbt/log_private.h"
+#include "xbt/dynar.h"
+#include "xbt/xbt_os_thread.h"
+
+XBT_PUBLIC_DATA(int) (*xbt_pid) ();
+int xbt_log_no_loc = 0; /* if set to true (with --log=no_loc), file localization will be omitted (for tesh tests) */
+static xbt_os_rmutex_t log_cat_init_mutex = NULL;
+
+/** \addtogroup XBT_log
+ *
+ * This section describes the API to the log functions used
+ * everywhere in this project.
+
+\section XBT_log_toc Table of contents
+
+ - \ref log_overview
+ - \ref log_cat
+ - \ref log_pri
+ - \ref log_app
+ - \ref log_hist
+ - \ref log_API
+ - \ref log_API_cat
+ - \ref log_API_pri
+ - \ref log_API_isenabled
+ - \ref log_API_subcat
+ - \ref log_API_easy
+ - \ref log_API_example
+ - \ref log_user
+ - \ref log_use_conf
+ - \ref log_use_conf_thres
+ - \ref log_use_conf_multi
+ - \ref log_use_conf_fmt
+ - \ref log_use_conf_app
+ - \ref log_use_conf_add
+ - \ref log_use_misc
+ - \ref log_internals
+ - \ref log_in_perf
+ - \ref log_in_app
+ - \ref XBT_log_cats
+
+\section log_overview 1. Introduction
+
+This module is in charge of handling the log messages of every SimGrid
+program. The main design goal are:
+
+ - <b>configurability</b>: the user can choose <i>at runtime</i> what messages to show and
+ what to hide, as well as how messages get displayed.
+ - <b>ease of use</b>: both to the programmer (using preprocessor macros black magic)
+ and to the user (with command line options)
+ - <b>performances</b>: logging shouldn't slow down the program when turned off, for example
+ - deal with <b>distributed settings</b>: SimGrid programs are [often] distributed ones,
+ and the logging mechanism allows to syndicate each and every log source into the same place.
+ At least, its design would allow to, once we write the last missing pieces
+
+There is three main concepts in SimGrid's logging mechanism: <i>category</i>,
+<i>priority</i> and <i>appender</i>. These three concepts work together to
+enable developers to log messages according to message type and priority, and
+to control at runtime how these messages are formatted and where they are
+reported.
+
+\subsection log_cat 1.1 Category hierarchy
+
+The first and foremost advantage of any logging API over plain printf()
+resides in its ability to disable certain log statements while allowing
+others to print unhindered. This capability assumes that the logging space,
+that is, the space of all possible logging statements, is categorized
+according to some developer-chosen criteria.
+
+This observation led to choosing category as the central concept of the
+system. In a certain sense, they can be considered as logging topics or
+channels.
+
+\subsection log_pri 1.2 Logging priorities
+
+The user can naturally declare interest into this or that logging category, but
+he also can specify the desired level of details for each of them. This is
+controlled by the <i>priority</i> concept (which should maybe be renamed to
+<i>severity</i>).
+
+Empirically, the user can specify that he wants to see every debugging message
+of GRAS while only being interested into the messages at level "error" or
+higher about the XBT internals.
+
+\subsection log_app 1.3 Message appenders
+
+The message appenders are the elements in charge of actually displaying the
+message to the user. For now, only two appenders exist: the default one prints
+stuff on stderr while it is possible to create appenders printing to a specific
+file.
+
+Other are planed (such as the one sending everything to a remote server,
+or the one using only a fixed amount of lines in a file, and rotating content on
+need). One day, for sure ;)
+
+\subsection log_lay 1.4 Message layouts
+
+The message layouts are the elements in charge of choosing how each message
+will look like. Their result is a string which is then passed to the appender
+attached to the category to be displayed.
+
+For now, there is two layouts: The simple one, which is good for most cases,
+and another one allowing users to specify the format they want.
+\ref log_use_conf provides more info on this.
+
+\subsection log_hist 1.5 History of this module
+
+Historically, this module is an adaptation of the log4c project, which is dead
+upstream, and which I was given the permission to fork under the LGPL licence
+by the log4c's authors. The log4c project itself was loosely based on the
+Apache project's Log4J, which also inspired Log4CC, Log4py and so on. Our work
+differs somehow from these projects anyway, because the C programming language
+is not object oriented.
+
+\section log_API 2. Programmer interface
+
+\subsection log_API_cat 2.1 Constructing the category hierarchy
+
+Every category is declared by providing a name and an optional
+parent. If no parent is explicitly named, the root category, LOG_ROOT_CAT is
+the category's parent.
+
+A category is created by a macro call at the top level of a file. A
+category can be created with any one of the following macros:
+
+ - \ref XBT_LOG_NEW_CATEGORY(MyCat,desc); Create a new root
+ - \ref XBT_LOG_NEW_SUBCATEGORY(MyCat, ParentCat,desc);
+ Create a new category being child of the category ParentCat
+ - \ref XBT_LOG_NEW_DEFAULT_CATEGORY(MyCat,desc);
+ Like XBT_LOG_NEW_CATEGORY, but the new category is the default one
+ in this file
+ - \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, ParentCat,desc);
+ Like XBT_LOG_NEW_SUBCATEGORY, but the new category is the default one
+ in this file
+
+The parent cat can be defined in the same file or in another file (in
+which case you want to use the \ref XBT_LOG_EXTERNAL_CATEGORY macro to make
+it visible in the current file), but each category may have only one
+definition. Likewise, you can use a category defined in another file as
+default one using \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY
+
+Typically, there will be a Category for each module and sub-module, so you
+can independently control logging for each module.
+
+For a list of all existing categories, please refer to the \ref XBT_log_cats
+section. This file is generated automatically from the SimGrid source code, so
+it should be complete and accurate.
+
+\section log_API_pri 2.2 Declaring message priority
+
+A category may be assigned a threshold priority. The set of priorities are
+defined by the \ref e_xbt_log_priority_t enum. All logging request under
+this priority will be discarded.
+
+If a given category is not assigned a threshold priority, then it inherits
+one from its closest ancestor with an assigned threshold. To ensure that all
+categories can eventually inherit a threshold, the root category always has
+an assigned threshold priority.
+
+Logging requests are made by invoking a logging macro on a category. All of
+the macros have a printf-style format string followed by arguments. If you
+compile with the -Wall option, gcc will warn you for unmatched arguments, ie
+when you pass a pointer to a string where an integer was specified by the
+format. This is usually a good idea.
+
+Here is an example of the most basic type of macro. This is a logging
+request with priority <i>warning</i>.
+
+<code>XBT_CLOG(MyCat, gras_log_priority_warning, "Values are: %d and '%s'", 5,
+"oops");</code>
+
+A logging request is said to be enabled if its priority is higher than or
+equal to the threshold priority of its category. Otherwise, the request is
+said to be disabled. A category without an assigned priority will inherit
+one from the hierarchy.
+
+It is possible to use any non-negative integer as a priority. If, as in the
+example, one of the standard priorities is used, then there is a convenience
+macro that is typically used instead. For example, the above example is
+equivalent to the shorter:
+
+<code>XBT_CWARN(MyCat, "Values are: %d and '%s'", 5, "oops");</code>
+
+\section log_API_isenabled 2.3 Checking if a particular category/priority is enabled
+
+It is sometimes useful to check whether a particular category is
+enabled at a particular priority. One example is when you want to do
+some extra computation to prepare a nice debugging message. There is
+no use of doing so if the message won't be used afterward because
+debugging is turned off.
+
+Doing so is extremely easy, thanks to the XBT_LOG_ISENABLED(category, priority).
+
+\section log_API_subcat 2.4 Using a default category (the easy interface)
+
+If \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, Parent) or
+\ref XBT_LOG_NEW_DEFAULT_CATEGORY(MyCat) is used to create the
+category, then the even shorter form can be used:
+
+<code>XBT_WARN("Values are: %s and '%d'", 5, "oops");</code>
+
+Only one default category can be created per file, though multiple
+non-defaults can be created and used.
+
+\section log_API_easy 2.5 Putting all together: the easy interface
+
+First of all, each module should register its own category into the categories
+tree using \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY.
+
+Then, logging should be done with the #XBT_DEBUG, #XBT_VERB, #XBT_INFO,
+#XBT_WARN, #XBT_ERROR and #XBT_CRITICAL macros.
+
+Under GCC, these macro check there arguments the same way than printf does. So,
+if you compile with -Wall, the following code will issue a warning:
+<code>XBT_DEBUG("Found %s (id %d)", some_string, a_double)</code>
+
+If you want to specify the category to log onto (for example because you
+have more than one category per file, add a C before the name of the log
+producing macro (ie, use #XBT_CDEBUG, #XBT_CVERB, #XBT_CINFO, #XBT_CWARN,
+#XBT_CERROR and #XBT_CCRITICAL and friends), and pass the category name as
+first argument.
+
+The TRACE priority is not used the same way than the other. You should use
+the #XBT_IN, #XBT_OUT and #XBT_HERE macros instead.
+
+\section log_API_example 2.6 Example of use
+
+Here is a more complete example:
+
+\verbatim
+#include "xbt/log.h"
+
+/ * create a category and a default subcategory * /
+XBT_LOG_NEW_CATEGORY(VSS);
+XBT_LOG_NEW_DEFAULT_SUBCATEGORY(SA, VSS);
+
+int main() {
+ / * Now set the parent's priority. (the string would typcially be a runtime option) * /
+ xbt_log_control_set("SA.thresh:3");