[libmicrohttpd] 01/02: MHD_set_panic_func: clarified doxy

[gnunet]

This is an automated email from the git hooks/post-receive script.

karlson2k pushed a commit to branch master
in repository libmicrohttpd.

commit efdd6e0ffbc597a95165bd328d3acd608cdcaa5b
Author: Evgeny Grin (Karlson2k) <k2k@narod.ru>
AuthorDate: Mon Apr 25 22:50:47 2022 +0300

    MHD_set_panic_func: clarified doxy
---
 src/include/microhttpd.h   | 25 ++++++++++++++-----------
 src/microhttpd/mhd_panic.c | 20 +++++++++++---------
 2 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/src/include/microhttpd.h b/src/include/microhttpd.h
index b4bc85e3..06ca6964 100644
--- a/src/include/microhttpd.h
+++ b/src/include/microhttpd.h
@@ -2355,7 +2355,8 @@ enum MHD_DaemonInfoType
  * an error message and `abort()`.
  *
  * @param cls user specified value
- * @param file where the error occurred
+ * @param file where the error occurred, may be NULL if MHD was built without
+ *             messages support
  * @param line where the error occurred
  * @param reason error detail, may be NULL
  * @ingroup logging
@@ -3138,16 +3139,18 @@ MHD_set_connection_value_n (struct MHD_Connection 
*connection,
 
 
 /**
- * Sets the global error handler to a different implementation.  @a cb
- * will only be called in the case of typically fatal, serious
- * internal consistency issues.  These issues should only arise in the
- * case of serious memory corruption or similar problems with the
- * architecture.  While @a cb is allowed to return and MHD will then
- * try to continue, this is never safe.
- *
- * The default implementation that is used if no panic function is set
- * simply prints an error message and calls `abort()`.  Alternative
- * implementations might call `exit()` or other similar functions.
+ * Sets the global error handler to a different implementation.
+ *
+ * @a cb will only be called in the case of typically fatal, serious internal
+ * consistency issues or serious system failures like failed lock of mutex.
+ *
+ * These issues should only arise in the case of serious memory corruption or
+ * similar problems with the architecture, there is no safe way to continue
+ * even for closing of the application.
+ *
+ * The default implementation that is used if no panic function is set simply
+ * prints an error message and calls `abort()`.
+ * Alternative implementations might call `exit()` or other similar functions.
  *
  * @param cb new error handler or NULL to use default handler
  * @param cls passed to @a cb
diff --git a/src/microhttpd/mhd_panic.c b/src/microhttpd/mhd_panic.c
index ae2db248..dfe1f6b5 100644
--- a/src/microhttpd/mhd_panic.c
+++ b/src/microhttpd/mhd_panic.c
@@ -73,16 +73,18 @@ mhd_panic_std (void *cls,
 
 
 /**
- * Sets the global error handler to a different implementation.  @a cb
- * will only be called in the case of typically fatal, serious
- * internal consistency issues.  These issues should only arise in the
- * case of serious memory corruption or similar problems with the
- * architecture.  While @a cb is allowed to return and MHD will then
- * try to continue, this is never safe.
+ * Sets the global error handler to a different implementation.
  *
- * The default implementation that is used if no panic function is set
- * simply prints an error message and calls `abort()`.  Alternative
- * implementations might call `exit()` or other similar functions.
+ * @a cb will only be called in the case of typically fatal, serious internal
+ * consistency issues or serious system failures like failed lock of mutex.
+ *
+ * These issues should only arise in the case of serious memory corruption or
+ * similar problems with the architecture, there is no safe way to continue
+ * even for closing of the application.
+ *
+ * The default implementation that is used if no panic function is set simply
+ * prints an error message and calls `abort()`.
+ * Alternative implementations might call `exit()` or other similar functions.
  *
  * @param cb new error handler or NULL to use default handler
  * @param cls passed to @a cb

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.