We were already asserting that the intmax_t and uintmax_t types
are the same as int64_t and uint64_t. Pretty much everywhere in
the code base we use the latter types. In principle intmax_t could
be something different on some new architecture, and then the code would
fail to compile or behave differently. We actually do not want the code
to behave differently on those architectures, because that'd break
interoperability. So let's just use int64_t/uint64_t since that's what
we indend to use.
It seems that the implementation of long double on ppc64el doesn't really work:
long double cast to integer and back compares as unequal to itself. Strangely,
this effect happens without optimization and both with gcc and clang, so it
seems to be an effect of how long double is implemented by the architecture.
Dumping the values shows the following pattern:
00 00 00 00 00 00 24 40 00 00 00 00 00 00 00 00 # long double v = 10;
00 00 00 00 00 00 24 40 00 00 00 00 00 00 80 39 # (long double)(intmax_t) v
Instead of trying to make this work, I think it's most reasonable to switch to
normal doubles. Notably, we had no tests for floating point behaviour. The
first test we added (for values even not in the range outside of double),
showed failures.
Common implementations of JSON (in particular JavaScript) use 64 bit double.
If we stick to this, users are likely to be happy when they exchange data with
those tools. Exporting values that cannot be represented in other tools would
just cause interop problems.
I don't think the extra precision would be much used. Long double seems to make
most sense as a transient format used in calculations to get extra precision in
operations, and not a storage or exchange format. So I expect low-level
numerical routines that have to know about hardware to make use of it, but it
shouldn't be used by our (higher-level) system library. In particular, we would
have to add tests for implementations conforming to IEEE 754, and those that
don't conform, and account for various implementation differences. It just
doesn't seem worth the effort.
https://en.wikipedia.org/wiki/Long_double#Implementations shows that the
situation is "complicated":
> On the x86 architecture, most C compilers implement long double as the 80-bit
> extended precision type supported by x86 hardware. An exception is Microsoft
> Visual C++ for x86, which makes long double a synonym for double. The Intel
> C++ compiler on Microsoft Windows supports extended precision, but requires
> the /Qlong‑double switch for long double to correspond to the hardware's
> extended precision format.
> Compilers may also use long double for the IEEE 754 quadruple-precision
> binary floating-point format (binary128). This is the case on HP-UX,
> Solaris/SPARC, MIPS with the 64-bit or n32 ABI, 64-bit ARM (AArch64) (on
> operating systems using the standard AAPCS calling conventions, such as
> Linux), and z/OS with FLOAT(IEEE). Most implementations are in software, but
> some processors have hardware support.
> On some PowerPC and SPARCv9 machines, long double is implemented as a
> double-double arithmetic, where a long double value is regarded as the exact
> sum of two double-precision values, giving at least a 106-bit precision; with
> such a format, the long double type does not conform to the IEEE
> floating-point standard. Otherwise, long double is simply a synonym for
> double (double precision), e.g. on 32-bit ARM, 64-bit ARM (AArch64) (on
> Windows and macOS) and on 32-bit MIPS (old ABI, a.k.a. o32).
> With the GNU C Compiler, long double is 80-bit extended precision on x86
> processors regardless of the physical storage used for the type (which can be
> either 96 or 128 bits). On some other architectures, long double can be
> double-double (e.g. on PowerPC) or 128-bit quadruple precision (e.g. on
> SPARC). As of gcc 4.3, a quadruple precision is also supported on x86, but as
> the nonstandard type __float128 rather than long double.
> Although the x86 architecture, and specifically the x87 floating-point
> instructions on x86, supports 80-bit extended-precision operations, it is
> possible to configure the processor to automatically round operations to
> double (or even single) precision. Conversely, in extended-precision mode,
> extended precision may be used for intermediate compiler-generated
> calculations even when the final results are stored at a lower precision
> (i.e. FLT_EVAL_METHOD == 2). With gcc on Linux, 80-bit extended precision is
> the default; on several BSD operating systems (FreeBSD and OpenBSD),
> double-precision mode is the default, and long double operations are
> effectively reduced to double precision. (NetBSD 7.0 and later, however,
> defaults to 80-bit extended precision). However, it is possible to override
> this within an individual program via the FLDCW "floating-point load
> control-word" instruction. On x86_64, the BSDs default to 80-bit extended
> precision. Microsoft Windows with Visual C++ also sets the processor in
> double-precision mode by default, but this can again be overridden within an
> individual program (e.g. by the _controlfp_s function in Visual C++). The
> Intel C++ Compiler for x86, on the other hand, enables extended-precision
> mode by default. On IA-32 OS X, long double is 80-bit extended precision.
So, in short, the only thing that can be said is that nothing can be said. In
common scenarios, we are getting only a bit of extra precision (80 bits instead
of 64), but use space for padding. In other scenarios we are getting no extra
precision. And the variance in implementations is a big issue: we can expect
strange differences in behaviour between architectures, systems, compiler
versions, compilation options, and even the other things that the program is
doing.
Fixes#21390.
Let's not refuse low or high disk sizes unnecessarily early. They disk
sizes are subject fs limits anyway, hence there's no point in adding
another limit.
Relaxing thhe rules here as the advantage that we can later allow
"homectl resize lennart 0" as a generic way to minimize disk space.
Previously the mkdir_label() family of calls was implemented in
src/shared/mkdir-label.c but its functions partly declared ins
src/shared/label.h and partly in src/basic/mkdir.h (!!). That's weird
(and wrong).
Let's clean this up, and add a proper mkdir-label.h matching the .c
file.
Let's reduce our code duplication, and let's focus on using xyzat()
style APIs more, hence drop mkdir_errno_wrapper() and stick to
mkdirar_errno_wrapper() wherever we can, it's a true superset of
functionality after all.
Let's make sure mac_selinux_create_file_prepare_at() works fine with
AT_FDCWD, and then make mac_selinux_create_file_prepare() just a inline
wrapper around it.
The man page doesn't quite match what --help says, and I needed to use "-f" to
write a wiped partition. This all feels a bit experimental, but the fs has some
adherents, and we should make it easy to use.
(Also, an empty 256MB device formatted and mounted shows up as
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 254M 85M 170M 34% /var/tmp/mount
which also seems a bit over the top…)
Requested in https://github.com/systemd/systemd/pull/21275#issuecomment-967928690.
Apparently mkswap has it's own limit, and it seems to be one lower than the one
for ext2/3/4.
$ for i in ext2 ext3 ext4 btrfs xfs vfat swap minix; do
echo $i && wipefs -q -a '/var/tmp/głąbźśńćąśððð.img'
build/systemd-makefs $i '/var/tmp/głąbźśńćąśððð.img'
done
ext2
/var/tmp/głąbźśńćąśððð.img successfully formatted as ext2 (label "głąbźśńćą", uuid 7626bc5c-8ac4-43cf-87b7-1b2761272dd3)
ext3
/var/tmp/głąbźśńćąśððð.img successfully formatted as ext3 (label "głąbźśńćą", uuid 0da22cad-0dbf-4a7a-962d-12cd39d006b5)
ext4
/var/tmp/głąbźśńćąśððð.img successfully formatted as ext4 (label "głąbźśńćą", uuid dded267b-8955-4d19-82a5-1f231d446059)
btrfs
/var/tmp/głąbźśńćąśððð.img successfully formatted as btrfs (label "głąbźśńćąśððð.img", uuid 9e2e89f1-010d-4ab6-80f3-f9e215dbc225)
xfs
/var/tmp/głąbźśńćąśððð.img successfully formatted as xfs (label "głąbźśń", uuid 2cc937af-4c41-465c-8f52-aab2304bd860)
vfat
mkfs.fat 4.2 (2021-01-31)
/var/tmp/głąbźśńćąśððð.img successfully formatted as vfat (label "G__B_______", uuid a3a9e028)
swap
...
LABEL=głąbźśńć, UUID=0ab787aa-37a6-4b32-978b-d71efc6e6098
/var/tmp/głąbźśńćąśððð.img successfully formatted as swap (label "głąbźśńć", uuid 0ab787aa-37a6-4b32-978b-d71efc6e6098)
minix
...
/var/tmp/głąbźśńćąśððð.img successfully formatted as minix (no label or uuid specified)
I was testing with a "test1.img" and mkfs.vfat rejects "TEST1.IMG" with the
error "Labels with characters *?.,;:/\|+=<>[]" are not allowed". So let's
replace those characters with "_".
With glibc-2.34.9000-17.fc36.x86_64, dynamically programs newly fail in early
init with a restrictive syscall filter that does not include @system-service.
I think this is caused by 2dd87703d4386f2776c5b5f375a494c91d7f9fe4:
Author: Florian Weimer <fweimer@redhat.com>
Date: Mon May 10 10:31:41 2021 +0200
nptl: Move changing of stack permissions into ld.so
All the stack lists are now in _rtld_global, so it is possible
to change stack permissions directly from there, instead of
calling into libpthread to do the change.
It seems that this call will now be very widely used, so let's just move it to
default to avoid too many failures.
