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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Coverity complained about this code and is partially right. We are not
really protected against integer overflows. Sure, unlikely, but lets just
avoid any overflows and properly protect our parser loop.
Lets return the parsed length in term_utf8_decode() instead of a buffer
pointer. Store the pointer in the passed argument.
This makes it adhere to the systemd coding-style, were we always avoid
returning pointers, but store them in output arguments. In this case, the
storage is not allocated, so it doesn't fit 100% to this idiom, but still
looks much nicer.
We currently select front-buffers as new back-buffer if they happen to be
the last buffer in our framebuffer-array. Fix this by never selecting a
new front buffer as back buffer.
Spotted with coverity. If parsing both /etc/os-release and
/usr/lib/os-release fails then null would be passed on. The calls
to parse the two files are allowed to fail. A empty /etc may not
have had the /etc/os-release symlink restored yet and we just
try again in the loop. If for whatever reason that does not happen
then we now pass on 'n/a' instead of null.
Coverity seems to think that we can later end up with the "them"
fd having a negative value. Even after a succesful barrier_create.
Add some test to verify that the constructor went well. If coverity
still complains then it must mean that it thinks the the value is
overwritten later.
Example from Tom Gundersen is included using xi:include.
The copyright notice stands out a bit. Maybe it should be removed,
and the code placed in public domain.
The caller may have an existing DUID that it wants to use, and may
want to use some other DUID generation scheme than systemd's
default DUID-EN.
[tomegun: whitespace - we never use tabs]
This patch adds a transient user unit directory under
`$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance
units (such as those created by `systemd-run --user`) under there
instead of putting them in $XDG_CONFIG_HOME/systemd/user/.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
We cannot rely on "errno" to be non-zero on failure, if we perform
multiple glibc calls. That is, if the first eventfd() call fails, but the
second succeeds, we cleanup the barrier but return 0.
Fix this by always testing the return value immediately. This should also
fix all the coverity warnings.
All the definitions are for outside users, so drop the -internal suffix.
Internal definitions are in unifont-def.h and unifont.c, no need to share
those.
D-Bus' type hierarchy as described in the spec is:
\- basic
\- fixed type (u, i, etc.)
\- string-like type (s, o, g)
\- container
Someone seems to have referred to basic types as "simple types" at
some point, but that term isn't defined in the D-Bus Specification,
and seems redundant.
So far I haven't renamed functions that use "trivial" in their names
to mean "fixed type", to avoid confusion about whether a struct of
constant length, like (iu), is a fixed type. The answer is that it is
fixed-length, but is not a "fixed type", so I can see that something
like bus_type_is_fixed() might be ambiguous.
We used to make all .swap units either RequiredBy=swap.target or
WantedBy=swap.target. But swap.target should be the "configured swap
units", either through /etc/fstab or non-generated .swap units. It
is surprising when systemd starts treating a swap device that was
possibly temporarily enabled as a hard dependency for other units.
So do not add dependencies with swap.target for units gleaned from
/proc/swaps.
Similarly, we added dependencies for all aliases of the device name,
which clutters up the dependency graph but does not seem to bring any
value, since the status of those following units is consistent with
the main one anyway.
This should be a fix for [1], and it seems the right thing to do
anyway.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1114786
In pty.c there was both an include of our pty.h and the system installed pty.h.
The latter contains only two functions openpty and forkpty. We use neither so
I assume it was a typo and removed it. We still compile and pass all tests.
