summaryrefslogtreecommitdiff
path: root/common/message.c
Commit message (Collapse)AuthorAgeFilesLines
* build: Don't use locale funcs if locale_t is not defined in locale.hDaiki Ueno2018-05-281-2/+2
| | | | | | On macOS, locale_t is not defined in <locale.h>. Although it is defined in <xlocale.h>, we rather not use locales at all for POSIX compliance.
* library: Use dedicated locale object for printing errorDaiki Ueno2018-05-011-7/+7
|
* Revert "build: Check strerror_l() and uselocale() seperately"Daiki Ueno2018-05-011-7/+2
| | | | | | | | | This reverts commit 173ad93cc54057886b2055f3d73ea64a047127d1. We should rather use newlocale() when per-thread locale is not set. Otherwise uselocale() could return LC_GLOBAL_LOCALE on some platforms (e.g. musl-libc) and calling strerror_l() with it leads to an undefined behavior.
* build: Check strerror_l() and uselocale() seperatelyDaiki Ueno2018-04-191-2/+7
| | | | | | NetBSD deliberately doesn't support per-thread locale and our thread-safe replacement of strerror() using strerror_l() cannot be used. Fallback to strerror_r() in that case.
* Be silent by default and do not print messages on stderrNikos Mavrogiannopoulos2017-06-261-1/+1
| | | | | | | | | As p11-kit is a library there are cases where it is not desirable to log on stderr by default. See for example this report https://bugzilla.redhat.com/show_bug.cgi?id=1464490 where wget prints an error due to an unconfigured pkcs11 module. Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
* compat: Prefer strerror_l to strerror_rDaiki Ueno2017-06-121-1/+14
| | | | | strerror_r is being obsolete in the next POSIX specification: http://austingroupbugs.net/view.php?id=655
* Don't use _GNU_SOURCE and fix strerror_r usageStef Walter2013-07-231-0/+6
| | | | | glibc declares strerror_r completely different if in POSIX or GNU mode. Nastiness. Stop using _GNU_SOURCE all together.
* Avoid using the non-thread-safe strerror() functionStef Walter2013-07-181-0/+26
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=985481
* Separate library init from message codeStef Walter2013-04-031-0/+140
Put library init/uninit code its into their own statically linked library so that they don't get linked into the p11-kit executable. Refactor the message code so that the library initialization can plug in its per thread message buffer. https://bugs.freedesktop.org/show_bug.cgi?id=63046
generated by cgit v1.1 at 2024-12-28 15:56:46 +0000