IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The ELF magic cannot work for consumers of our shard library, since they
are in a different module. Hence make all the ELF magic private, and
instead introduce a public function to register additional static
mapping table.
Several different systemd tools define a nulstr containing a standard
series of configuration file directories, in /etc, /run, /usr/local/lib,
/usr/lib, and (#ifdef HAVE_SPLIT_USR) /lib. Factor that logic out into
a new helper macro, CONF_DIRS_NULSTR.
Similar to container_of(), we now use unique variable names for the bascic
math macros MAX, MIN, CLAMP, LESS_BY. Furthermore, unit tests are added to
verify they work as expected.
For a rationale, see:
commit fb835651af
Author: David Herrmann <dh.herrmann@gmail.com>
Date: Fri Aug 22 14:41:37 2014 +0200
shared: make container_of() use unique variable names
If you stack container_of() macros, you will get warnings due to shadowing
variables of the parent context. To avoid this, use unique names for
variables.
Two new helpers are added:
UNIQ: This evaluates to a truly unique value never returned by any
evaluation of this macro. It's a shortcut for __COUNTER__.
UNIQ_T: Takes two arguments and concatenates them. It is a shortcut for
CONCATENATE, but meant to defined typed local variables.
As you usually want to use variables that you just defined, you need to
reference the same unique value at least two times. However, UNIQ returns
a new value on each evaluation, therefore, you have to pass the unique
values into the macro like this:
#define my_macro(a, b) __max_macro(UNIQ, UNIQ, (a), (b))
#define __my_macro(uniqa, uniqb, a, b) ({
typeof(a) UNIQ_T(A, uniqa) = (a);
typeof(b) UNIQ_T(B, uniqb) = (b);
MY_UNSAFE_MACRO(UNIQ_T(A, uniqa), UNIQ_T(B, uniqb));
})
This way, MY_UNSAFE_MACRO() can safely evaluate it's arguments multiple
times as they are local variables. But you can also stack invocations to
the macro my_macro() without clashing names.
This is the same as if you did:
#define my_macro(a, b) __max_macro(__COUNTER__, __COUNTER__, (a), (b))
#define __my_macro(prefixa, prefixb, a, b) ({
typeof(a) CONCATENATE(A, prefixa) = (a);
typeof(b) CONCATENATE(B, prefixb) = (b);
MY_UNSAFE_MACRO(CONCATENATE(A, prefixa), CONCATENATE(B, prefixb));
})
...but in my opinion, the first macro is easier to write and read.
This patch starts by converting container_of() to use this new helper.
Other macros may follow (like MIN, MAX, CLAMP, ...).
The UNIQUE() macro works fine if used in un-stacked macros. However, once
you stack them like:
MAX(MIN(a, b),
CLAMP(MAX(c, d), e, f))
you will get warnings due to shadowing other variables. gcc uses the last
line of a macro expansion as value for __LINE__, therefore, we cannot even
avoid this by splitting the expressions across lines.
Remove the only user of UNIQUE() so we introduce a new helper in
follow-ups.
The MAXSIZE() macro takes two types and returns the size of the larger
one. It is much simpler to use than MAX(sizeof(A), sizeof(B)) and also
avoids any compiler-extensions, unlike CONST_MAX() and MAX() (which are
needed to avoid evaluating arguments more than once). This was suggested
by Daniele Nicolodi <daniele@grinta.net>.
Also make resolved use this macro instead of CONST_MAX(). This enhances
readability quite a bit.
The CONST_MAX() macro is similar to MAX(), but verifies that both
arguments have the same type and are constant expressions. Furthermore,
the result of CONST_MAX() is again a constant-expression.
CONST_MAX() avoids any statement-expressions and other non-trivial
expression-types. This avoids rather arbitrary restrictions in both GCC
and LLVM, which both either fail with statement-expressions inside
type-declarations or statement-expressions inside static-const
initializations.
If anybody knows how to circumvent this, please feel free to unify
CONST_MAX() and MAX().
We must add 'const' to local variables in statement-expressions to
guarantee that the macros can produce constant-expressions if given such.
GCC seems to ignore this, but LLVM/clang requires it (understandably).
Let's turn resolved into a something truly useful: a fully asynchronous
DNS stub resolver that subscribes to network changes.
(More to come: caching, LLMNR, mDNS/DNS-SD, DNSSEC, IDN, NSS module)
As it turns out, we cannot use _Pragma in compound-statements. Therefore,
constructs like MIN(MAX(a, b), x) will warn due to shadowed variable
declarations. The DISABLE_WARNING_SHADOW macro can be used to suppress
these.
Note that using UNIQUE(_var) does not work either as GCC uses the last
line of a macro-expansion for __LINE__, therefore, still causing both
macros to have the same variables. We could use different variable-names
for MIN and MAX, but that just hides the problem and still fails for
MIN(something(MIN(a, b)), c).
The only working solution is to use __COUNTER__ and pass it pre-evaluated
as extra argument to a macro to use as name-prefix. This, however, makes
all these macros much more complicated so I'll go with manual
DISABLE_WARNING_SHADOW so far.
Sounds easy, turns out to be horrible to implement: ALIGN_POWER2 returns
the next higher power of 2. clz(0) is undefined, same is true for
left-shift-overflows, yey, C rocks!
This way each user allocates from his own pool, with its own size limit.
This puts the size limit by default to 10% of the physical RAM size but
makes it configurable in logind.conf.
Before, journald would remove journal files until both MaxUse= and
KeepFree= settings would be satisfied. The first one depends (if set
automatically) on the size of the file system and is constant. But
the second one depends on current use of the file system, and a spike
in disk usage would cause journald to delete journal files, trying to
reach usage which would leave 15% of the disk free. This behaviour is
surprising for the user who doesn't expect his logs to be purged when
disk usage goes above 85%, which on a large disk could be some
gigabytes from being full. In addition attempting to keep 15% free
provides an attack vector where filling the disk sufficiently disposes
of almost all logs.
Instead, obey KeepFree= only as a limit on adding additional files.
When replacing old files with new, ignore KeepFree=. This means that
if journal disk usage reached some high point that at some later point
start to violate the KeepFree= constraint, journald will not add files
to go above this point, but it will stay (slightly) below it. When
journald is restarted, it forgets the previous maximum usage value,
and sets the limit based on the current usage, so if disk remains to
be filled, journald might use one journal-file-size less on each
restart, if restarts happen just after rotation. This seems like a
reasonable compromise between implementation complexity and robustness.
Introduce IN_SET() macro to nicely check whether a value a is one of a
few listed values.
This makes writing this:
if (a == 1 || a == 7 || a == 8 || a == 9)
nicer, by allowing this:
if (IN_SET(a, 1, 7, 8, 9))
This is particularly useful for state machine enums.
David:
I already applied a fix for that, but this patch definitely looks nicer. I
changed CONCATENATE_HELPER() -> XCONCATENATE() similar to XSTRINGIFY and
added the UNIQUE() helper.
As the name indicates assert_return() is really just for assertions,
i.e. where it's a programming error if the assertion does not hold.
Hence it is safe to add _unlikely_() decorators for the expression to
check.
For the library functions we expose we currently repeatedly use checks
like the following:
if (!value_is_ok(parameter1))
return -EINVAL;
if (!value_is_ok(parameter2))
return -EINVAL;
And so on. Let's turn this into a macro:
assert_return(value_is_ok(parameter1), -EINVAL);
assert_return(value_is_ok(paramater2), -EINVAL);
This makes our code a bit shorter and simpler, and also allows us to add
a _unlikely_() around the check.
It is imperative that open source code be well attributed.
Sprinkle attribute((alloc_size)) here and there, telling gcc
how much memory we are actually allocating.
This reverts commit 4826f0b7b5.
Because statfs.t_type can be int on some architecures, we have to cast
the const magic to the type, otherwise the compiler warns about
signed/unsigned comparison, because the magic can be 32 bit unsigned.
statfs(2) man page is also wrong on some systems, because
f_type is not __SWORD_TYPE on some architecures.
The following program:
int main(int argc, char**argv)
{
struct statfs s;
statfs(argv[1], &s);
printf("sizeof(f_type) = %d\n", sizeof(s.f_type));
printf("sizeof(__SWORD_TYPE) = %d\n", sizeof(__SWORD_TYPE));
printf("sizeof(long) = %d\n", sizeof(long));
printf("sizeof(int) = %d\n", sizeof(int));
if (sizeof(s.f_type) == sizeof(int)) {
printf("f_type = 0x%x\n", s.f_type);
} else {
printf("f_type = 0x%lx\n", s.f_type);
}
return 0;
}
executed on s390x gives for a btrfs:
sizeof(f_type) = 4
sizeof(__SWORD_TYPE) = 8
sizeof(long) = 8
sizeof(int) = 4
f_type = 0x9123683e
This reverts commit a858b64ddd.
This reverts commit aea275c431.
This reverts commit fc6e6d245e.
This reverts commit c4073a27c5.
This reverts commit cddf148028.
This reverts commit 8c68a70170.
The constants are now casted to __SWORD_TYPE, which should resolve the
compiler warnings about signed vs unsigned.
After talking to Kay, we concluded:
This should be fixed in the kernel, not worked around in userspace tools.
Architectures cannot use int and expect magic constants lager than INT_MAX
to work correctly. The kernel header needs to be fixed.
Even coreutils cannot handle it:
#define RAMFS_MAGIC 0x858458f6
# stat -f -c%t /
ffffffff858458f6
#define BTRFS_SUPER_MAGIC 0x9123683E
# stat -f -c%t /mnt
ffffffff9123683e
Although I found the perfect working macro to fix the thing :)
__extension__ ({ \
bool _ret = false; \
switch(f) { case c: _ret=true; }; \
( _ret ); \
})
On some architectures (like s390x) the kernel has the type int for
f_type, but long in userspace.
Assigning the 32 bit magic constants from linux/magic.h to the 31 bit
signed f_type in the kernel, causes f_type to be negative for some
constants.
glibc extends the int to long for those architecures in 64 bit mode, so
the negative int becomes a negative long, which cannot be simply
compared to the original magic constant, because the compiler would
automatically cast the constant to long.
To workaround this issue, we also compare to the (int)MAGIC value in a
macro. Of course, we could do #ifdef with the architecure, but it has to
be maintained, and the magic constants are 32 bit anyway.
Someday, when the int is unsigned or long for all architectures, we can
remove this macro again. Until then, keep it as simple as it can be.
There's now a generic _cleanup_ macro with an argument. The macros for
specific types are now defined using this macro, and in the header files
where they belong.
All cleanup handlers are now inline functions.
If we pass a constant value to ALIGN() gcc should have the chance to
calculate the value during compilation rather than runtime, so let's
avoid a static inline call if we can.
