fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-27 07:00:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/shared/nm-utils/nm-errno.h

186 lines
5.9 KiB
C
Raw Normal View History

shared,core: add "nm-errno.h" This will be our extension on top of <errno.h>. We want to use (integer) error numbers, that can both contain native errors from <errno.h> and our own defines, both merge in one domain. That is, we will reserve a small range of integers for our own defines (that hopefully won't clash with errors from <errno.h>). We can use this at places where GError is too cumbersome to use. The advantage is, that our error numbers extend <errno.h> and can be mixed. This is what "src/platform/nm-netlink.h" already does with nl_errno(). Next, the netlink errors from there will be merged into "nm-errno.h". Also, platform has NMPlatformError, which are a distinct set of error numbers. But these work differently in the sense that negative values represent codes from <errno.h> and positive numbers are our own platform specific defines. NMPlatformError will also be merged into "nm-errno.h". "nm-errno.h" will unify the error handling of platform and netlink, making it more similar to what we are used to from systemd, and give room to extend it for our own purpose.
2018-12-22 12:41:04 +01:00
/* NetworkManager -- Network link manager
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
* Boston, MA 02110-1301 USA.
*
* Copyright 2018 Red Hat, Inc.
*/
#ifndef __NM_ERRNO_H__
#define __NM_ERRNO_H__
#include <errno.h>
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
/*****************************************************************************/
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
enum _NMErrno {
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
_NM_ERRNO_MININT = G_MININT,
_NM_ERRNO_MAXINT = G_MAXINT,
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
_NM_ERRNO_RESERVED_FIRST = 100000,
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
/* when we cannot represent a number as positive number, we resort to this
* number. Basically, the values G_MININT, -NME_ERRNO_SUCCESS, NME_ERRNO_SUCCESS
* and G_MAXINT all map to the same value. */
NME_ERRNO_OUT_OF_RANGE = G_MAXINT,
/* Indicate that the original errno was zero. Zero denotes *no error*, but we know something
* went wrong and we want to report some error. This is a placeholder to mean, something
* was wrong, but errno was zero. */
NME_ERRNO_SUCCESS = G_MAXINT - 1,
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
/* an unspecified error. */
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
NME_UNSPEC = _NM_ERRNO_RESERVED_FIRST,
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
/* A bug, for example when an assertion failed.
* Should never happen. */
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
NME_BUG,
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
/* a native error number (from <errno.h>) cannot be mapped as
* an nm-error, because it is in the range [_NM_ERRNO_RESERVED_FIRST,
* _NM_ERRNO_RESERVED_LAST]. */
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
NME_NATIVE_ERRNO,
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
/* netlink errors. */
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
NME_NL_SEQ_MISMATCH,
NME_NL_MSG_TRUNC,
NME_NL_MSG_TOOSHORT,
NME_NL_DUMP_INTR,
NME_NL_ATTRSIZE,
NME_NL_BAD_SOCK,
NME_NL_NOADDR,
NME_NL_MSG_OVERFLOW,
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
/* platform errors. */
NME_PL_NOT_FOUND,
NME_PL_EXISTS,
NME_PL_WRONG_TYPE,
NME_PL_NOT_SLAVE,
NME_PL_NO_FIRMWARE,
NME_PL_OPNOTSUPP,
NME_PL_NETLINK,
NME_PL_CANT_SET_MTU,
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
_NM_ERRNO_RESERVED_LAST_PLUS_1,
_NM_ERRNO_RESERVED_LAST = _NM_ERRNO_RESERVED_LAST_PLUS_1 - 1,
};
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
/*****************************************************************************/
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
/* When we receive an errno from a system function, we can safely assume
* that the error number is not negative. We rely on that, and possibly just
* "return -errsv;" to signal an error. We also rely on that, because libc
* is our trusted base: meaning, if it cannot even succeed at setting errno
* according to specification, all bets are off.
*
* This macro returns the input argument, and asserts that the error variable
* is positive.
*
* In a sense, the macro is related to nm_errno_native() function, but the difference
* is that this macro asserts that @errsv is positive, while nm_errno_native() coerces
* negative values to be non-negative. */
#define NM_ERRNO_NATIVE(errsv) \
({ \
const int _errsv_x = (errsv); \
\
nm_assert (_errsv_x > 0); \
_errsv_x; \
})
/* Normalize native errno.
*
* Our API may return native error codes (<errno.h>) as negative values. This function
* takes such an errno, and normalizes it to their positive value.
*
* The special values G_MININT and zero are coerced to NME_ERRNO_OUT_OF_RANGE and NME_ERRNO_SUCCESS
* respectively.
* Other values are coerced to their inverse.
* Other positive values are returned unchanged.
*
* Basically, this normalizes errsv to be positive (taking care of two pathological cases).
*/
shared: move nm_errno() function to nm-errno.h No other changes (yet).
2018-12-22 13:09:21 +01:00
static inline int
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
nm_errno_native (int errsv)
shared: move nm_errno() function to nm-errno.h No other changes (yet).
2018-12-22 13:09:21 +01:00
{
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
switch (errsv) {
case 0: return NME_ERRNO_SUCCESS;
case G_MININT: return NME_ERRNO_OUT_OF_RANGE;
default:
return errsv >= 0 ? errsv : -errsv;
}
shared: move nm_errno() function to nm-errno.h No other changes (yet).
2018-12-22 13:09:21 +01:00
}
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
/* Normalizes an nm-error to be positive.
*
* Various API returns negative error codes, and this function converts the negative
* value to its positive.
*
* Note that @nmerr is on the domain of NetworkManager specific error numbers,
* which is not the same as the native error numbers (errsv from <errno.h>). But
* as far as normalizing goes, nm_errno() does exactly the same remapping as
* nm_errno_native(). */
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
static inline int
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
nm_errno (int nmerr)
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
{
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
return nm_errno_native (nmerr);
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
}
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
/* this maps a native errno to a (always non-negative) nm-error number.
*
* Note that nm-error numbers are embedded into the range of regular
* errno. The only difference is, that nm-error numbers reserve a
* range (_NM_ERRNO_RESERVED_FIRST, _NM_ERRNO_RESERVED_LAST) for their
* own purpose.
*
* That means, converting an errno to nm-error number means in
* most cases just returning itself.
* Only pathological cases need special handling:
*
* - 0 is mapped to NME_ERRNO_SUCCESS;
* - G_MININT is mapped to NME_ERRNO_OUT_OF_RANGE;
* - values in the range of (+/-) [_NM_ERRNO_RESERVED_FIRST, _NM_ERRNO_RESERVED_LAST]
* are mapped to NME_NATIVE_ERRNO
* - all other values are their (positive) absolute value.
*/
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
static inline int
trivial: rename nl-errno to nm-errno
2018-12-22 13:35:57 +01:00
nm_errno_from_native (int errsv)
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
{
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
switch (errsv) {
case 0: return NME_ERRNO_SUCCESS;
case G_MININT: return NME_ERRNO_OUT_OF_RANGE;
default:
shared: fix nm_errno_from_native() for negative input Fixes: 67130e67060b2bf28ce68c7714ea021227ece751
2019-02-12 09:12:45 +01:00
if (errsv < 0)
errsv = -errsv;
shared: cleanup separation and transition between errno and nmerr numbers The native error numbers (from <errno.h>) and our nmerr extention on top of them are almost the same. But there are peculiarities. Both errno and nmerr must be positive values. That is because some API (systemd) like to return negative error codes. So, a positive errno and its negative counter part indicate the same error. We need normalization functions that make an error number positive (these are nm_errno() and nm_errno_native()). This means, G_MININT needs special treatment, because it cannot be represented as a positive integer. Also, zero needs special treatment, because we want to encode an error, and zero already encodes no-error. Take care of these special cases. On top of that, nmerr reserves a range within native error numbers for NetworkManager specific failure codes. So we need to transition from native numbers to nmerr numbers via nm_errno_from_native(). Take better care of some special cases and clean them up. Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a value in the suitable range, NM_ERRNO_NATIVE() asserts that the number is already positive (and returns it as-is). It's use is only for asserting and implicitly documenting the requirements we have on the number passed to it.
2019-01-31 16:37:53 +01:00
return G_UNLIKELY ( errsv >= _NM_ERRNO_RESERVED_FIRST
&& errsv <= _NM_ERRNO_RESERVED_LAST)
? NME_NATIVE_ERRNO
: errsv;
shared: declare error numbers as enum and minor cleanup
2018-12-22 12:57:30 +01:00
}
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
}
trivial: rename nl-errno to nm-errno
2018-12-22 13:35:57 +01:00
const char *nm_strerror (int nmerr);
core: move netlink errors to nm-errno.h No other changes (yet).
2018-12-22 12:45:01 +01:00
/*****************************************************************************/
shared: add nm_strerror_native() to replace strerror() and g_strerror() We have various options for strerror(), with ups and downsides: - strerror() - returns pointer that is overwritten on next call. It's convenient to use, but dangerous. - not thread-safe. - not guaranteed to be UTF-8. - strerror_r() - takes input buffer and is less convenient to use. At least, we are in control of when the buffer gets overwritten. - there is a Posix/XSI and a glibc variant, making it sligthly inconvenient to used. This could be solved by a wrapper we implement. - thread-safe. - not guaranteed to be UTF-8. - g_strerror() - convenient and safe to use. Also the buffer is never released for the remainder of the program. - passing untrusted error numbers to g_strerror() can result in a denial of service, as the internal buffer grows until out-of-memory. - thread-safe. - guaranteed to be UTF-8 (depending on locale). Add our own wrapper nm_strerror_native(). It is: - convenient to use (returning a buffer that does not require management). - slightly dangerous as the buffer gets overwritten on the next call (like strerror()). - thread-safe. - guaranteed to be UTF-8 (depending on locale). - doesn't keep an unlimited cache of strings, unlike g_strerror(). You can't have it all. g_strerror() is leaking all generated error messages. I think that is unacceptable, because it would mean we need to keep track where our error numbers come from (and trust libraries we use to only set a restricted set of known error numbers).
2019-01-31 13:17:26 +01:00
#define NM_STRERROR_BUFSIZE 1024
const char *nm_strerror_native_r (int errsv, char *buf, gsize buf_size);
const char *nm_strerror_native (int errsv);
/*****************************************************************************/
shared,core: add "nm-errno.h" This will be our extension on top of <errno.h>. We want to use (integer) error numbers, that can both contain native errors from <errno.h> and our own defines, both merge in one domain. That is, we will reserve a small range of integers for our own defines (that hopefully won't clash with errors from <errno.h>). We can use this at places where GError is too cumbersome to use. The advantage is, that our error numbers extend <errno.h> and can be mixed. This is what "src/platform/nm-netlink.h" already does with nl_errno(). Next, the netlink errors from there will be merged into "nm-errno.h". Also, platform has NMPlatformError, which are a distinct set of error numbers. But these work differently in the sense that negative values represent codes from <errno.h> and positive numbers are our own platform specific defines. NMPlatformError will also be merged into "nm-errno.h". "nm-errno.h" will unify the error handling of platform and netlink, making it more similar to what we are used to from systemd, and give room to extend it for our own purpose.
2018-12-22 12:41:04 +01:00
#endif /* __NM_ERRNO_H__ */
Reference in a new issue Copy permalink