Two additional stdio changes followed 86a16ada1e and need to be
reverted as part of the fflush fix.
This reverts commit 6e13794fbe.
This reverts commit bafaa70b6f.
Fixes: d09a3bf72c ("fflush: correct buffer handling in __sflush")
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42491
errno.h was added in 44cf1e5eb4, which has been reverted.
Fixes: d09a3bf72c ("fflush: correct buffer handling in __sflush")
Sponsored by: The FreeBSD Foundation
This fixes CVE-2014-8611 correctly.
The commit that purported to fix CVE-2014-8611 (805288c2f0) only hid
it behind another bug. Two later commits, 86a16ada1e and
44cf1e5eb4, attempted to address this new bug but mostly just confused
the issue. This commit rolls back the three previous changes and fixes
CVE-2014-8611 correctly.
The key to understanding the bug (and the fix) is that `_w` has
different meanings for different stream modes. If the stream is
unbuffered, it is always zero. If the stream is fully buffered, it is
the amount of space remaining in the buffer (equal to the buffer size
when the buffer is empty and zero when the buffer is full). If the
stream is line-buffered, it is a negative number reflecting the amount
of data in the buffer (zero when the buffer is empty and negative buffer
size when the buffer is full).
At the heart of `fflush()`, we call the stream's write function in a
loop, where `t` represents the return value from the last call and `n`
the amount of data that remains to be written. When the write function
fails, we need to move the unwritten data to the top of the buffer
(unless nothing was written) and adjust `_p` (which points to the next
free location in the buffer) and `_w` accordingly. These variables have
already been set to the values they should have after a successful
flush, so instead of adjusting them down to reflect what was written,
we're adjusting them up to reflect what remains.
The bug was that while `_p` was always adjusted, we only adjusted `_w`
if the stream was fully buffered. The fix is to also adjust `_w` for
line-buffered streams. Everything else is just noise.
Fixes: 805288c2f0
Fixes: 86a16ada1e
Fixes: 44cf1e5eb4
Sponsored by: Klara, Inc.
These sys/cdefs.h are not needed. Purge them. They are mostly left-over
from the $FreeBSD$ removal. A few in libc are still required for macros
that cdefs.h defines. Keep those.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42385
Forward compatibility code was added for running newer ino64 binaries on
older kernels as a transition aide. Now that ino64 has been in the tree
6 years, this code is no longer useful and should have been removed long
ago. Remove it now. Should be no user-visible changes at this point as
all the 'upgrade' scenarios it was intended for are long since past.
Also need to remove this stuff from rtld since the _foo versions
no longer exist.
Sponsored by: Netflix
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D42382
Add a note saying that the CLOCK_BOOTTIME is unrelated to FreeBSD's
kern.boottime sysctl. Make a minor tweak to markup.
Feedback from: pauammu
Sponsored by: Netflix
Differential Revsion: https://reviews.freebsd.org/D36037
While strlcpy and snprintf are somewhat similar, there's big differences
between strlcat and snprintf which leads to confusion. Remove the
comparison, since it's ultimately not that useful: the snprintf man page
has similar language to strlcpy, so it doesn't provide a better
reference. The two implementations are otherwise unrelated.
Reviewed by: bcr
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D27228
Conceptually very similar to timingsafe_bcmp(), but with comparison
logic inspired by Elijah Stone's fancy memcmp. A baseline (SSE)
implementation was omitted this time as I was not able to get it to
perform adequately. Best I got was 8% over the scalar version for
long inputs, but slower for short inputs.
Sponsored by: The FreeBSD Foundation
Approved by: security (cperciva)
Inspired by: https://github.com/moon-chilled/fancy-memcmp
Differential Revision: https://reviews.freebsd.org/D41696
Very straightforward and similar to memcmp(3). The code has
been written to use only instructions specified as having
data operand independent timing by Intel.
Sponsored by: The FreeBSD Foundation
Approved by: security (cperciva)
Differential Revision: https://reviews.freebsd.org/D41673
POSIX has accepted a proposal[1] to add glibc-compatible ptsname_r. It
indicates an error by returning the error number, rather than returning
-1 and setting errno. Update RETURN VALUES in ptsname_r's man page now
to encourage folks to test that the return value != 0 rather than == -1.
[1] https://www.austingroupbugs.net/bug_view_page.php?bug_id=508
Reported by: Collin Funk
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42204
The man page had `kern.ktrace.geniosize` but the sysctl node contains an
underscore.
PR: 274274
Reported by: Ivan Rozhuk
Sponsored by: The FreeBSD Foundation
The four functions more or less perform the same operation.
Reuse the same unit test with slight changes so we can cover
them all. Constant-time operation is not verified for the
timingsafe_* functions.
Sponsored by: The FreeBSD Foundation
Approved by: ngie
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41528
Extend the tests to permit loading an external memcmp function
and testing it over using the libc version. This was added by the
example of other tests in the test suite doing the same thing and
helped tremendously in development.
This change was originally part of D41442 but was taken out to
permit separate review as extrapolated from @ngie's request in
D41349.
Sponsored by: FreeBSD Foundation
Approved by: ngie
Differential Revision: https://reviews.freebsd.org/D41528
Compiler memory barriers do not prevent the CPU from executing the code
out of order. Switch to C11 atomics. This also lets us get rid of the
mutex; instead, loop until the compare_exchange succeeds.
While here, change the return value of at_quick_exit() on failure to
the more traditional -1, matching atexit().
Sponsored by: Klara, Inc.
Reviewed by: Olivier Certner, kevans, kib
Differential Revision: https://reviews.freebsd.org/D41936
- cast GETNEXT to unsigned where it is being promoted to int to prevent
sign-extension (really it would have been better for PEEK*() and
GETNEXT() to return unsigned char; this would have removed a ton of
(uch) casts, but it is too intrusive for now).
- fix an isalpha that should have been iswalpha
PR: 264275, 274032
Reviewed by: kevans, eugen (previous version)
Obtained from: NetBSD
Differential Revision: https://reviews.freebsd.org/D41947
This extends the strcspn() unit tests to catch mistakes in the
implementation that only appear when a mismatch occurs in a certain
position of the string against a certain position of the set.
See also: 52d4a4d4e0
Sponsored by: The FreeBSD Foundation
Approved by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41821
When memcmp(a, b, len) (or equally, bcmp) is called with a phony length
such that a + len < a, the code would malfunction and not compare the
two buffers correctly. While such arguments are illegal (buffers do not
wrap around the end of the address space), it is neverthless conceivable
that people try things like memcmp(a, b, SIZE_MAX) to compare a and b
until the first mismatch, in the knowledge that such a mismatch exists,
expecting memcmp() to stop comparing somewhere around the mismatch.
While memcmp() is usually written to confirm to this assumption, no
version of ISO/IEC 9899 guarantees this behaviour (in contrast to
memchr() for which it is).
Neverthless it appears sensible to at least not grossly misbehave on
phony lengths. This change hardens memcmp() against this case by
comparing at least until the end of the address space if a + len
overflows a 64 bit integer.
Sponsored by: The FreeBSD Foundation
Approved by: mjg (blanket, via IRC)
See also: b2618b651b
MFC after: 1 week
When a string is matched against a set of 17--32 characters, each chunk
of the string is matched first against the first 16 characters of the
set and then against the remaining characters. We also check at the
same time if the string has a nul byte in the current chunk, terminating
the search if it does.
Due to misconceived logic, the order of checks was "first half of set,
nul byte, second half of set", meaning that a match with the second half
of the set was ignored when the string ended in the same 16 bytes.
Reverse the order of checks to fix this problem.
Sponsored by: The FreeBSD Foundation
Approved by: mjg (blanket, via IRC)
MFC after: 1 week
MFC to: stable/14
When memchr(buf, c, len) is called with a phony len (say, SIZE_MAX),
buf + len overflows and we have buf + len < buf. This confuses the
implementation and makes it return incorrect results. Neverthless we
must support this case as memchr() is guaranteed to work even with
phony buffer lengths, as long as a match is found before the buffer
actually ends.
Sponsored by: The FreeBSD Foundation
Reported by: yuri, des
Tested by: des
Approved by: mjg (blanket, via IRC)
MFC after: 1 week
MFC to: stable/14
PR: 273652
Now that we have an optimised memchr(3), we can use it to implement
strnlen(3) with better perofrmance.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41598
This is conceptually similar to strchr(3), but there are
slight changes to account for the buffer having an explicit
buffer length.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41598
This is conceptually very similar to the strcspn(3) implementations
from D41557, but we can't do the fast paths the same way.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41567
To cover the new optimised amd64 strspn(3) SIMD implementation, extend
the previously written strcspn(3) unit test to also cover strspn(3).
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41567
We currently use the NetBSD test suite to cover strcspn(3). It only
contains a very rudimentary test of this function. This all new set
of unit tests for the FreeBSD test suite should cover many more edge
cases relating to alignment issues.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41557
This changeset adds both a scalar and an x86-64-v2 implementation
of the strcspn(3) function to libc. A baseline implementation does not
appear to be feasible given the requirements of the function.
The scalar implementation is similar to the generic libc implementation,
but expands the bit set into a byte set to reduce latency, improving
performance. This approach could probably be backported to the generic
C version to benefit other platforms.
The x86-64-v2 implementation is built around the infamous pcmpistri
instruction. An alternative implementation based on the Muła/Langdale
algorithm [1] was prototyped, but performed worse than the pcmpistri
approach except for sets of more than 16 characters with long input
strings.
All implementations provide special cases for the empty set (reduces to
strlen as well as single-character sets (reduces to strchr). The
x86-64-v2 kernel falls back to the scalar implementation for sets of
more than 32 characters. This limit could be raised by additional
multiples of 16 through the use of additional pcmpistri code paths, but
I consider this case to be too rare to be of importance.
[1]: http://0x80.pl/articles/simd-byte-lookup.html
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41557
This adds test cases for %wN and %wfN to the printf(3) and scanf(3) tests.
While here, fix a few nits in the N2630 test cases.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41743
This adds specific width length modifiers in the form of wN and wfN (where N is 8, 16, 32, or 64) which allow printing intN_t and int_fastN_t without resorting to casts or PRI macros.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41725
LIBCSRCDIR is defined in bsd.libnames.mk, which is read in later in the
Makefile than the line:
.if exists(${LIBCSRCDIR}/${MACHINE_ARCH})
so we test to see if /${MARCHIN_ARCH} exists which it usually doesn't
(but did for me since I mounted 13.2R SD image there). Move to defining
our own LIBC_SRCTOP in terms of SRCTOP to treat these uniformily.
Sponsored by: Netflix
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D41661
With the new simd-dispatch framework documented in simd(7),
add cross-references to the new man pages to appropriate places.
Sponsored by: The FreeBSD Foundation
Approved by: emaste
MFC to: stable/14
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41697
While here, also update a mention of ANSI C.
Sponsored by: Klara, Inc.
Reviewed by: kevans, markj
Differential Revision: https://reviews.freebsd.org/D41686
This will enable alternative mallocs to be included in the tree and
selected by setting LIBC_MALLOC. As there is only one today (jemalloc)
this option does nothing, but we expect to add other implementations
in the future. This will also reduce diffs to CheriBSD.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D41660
strverscmp(3) and versionsort(3) where first released in 13.2
PR: 273401
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41617
This adds formatted input/output of binary integer numbers to the printf(), scanf(), and strtol() families, including their wide-character counterparts.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41511
When the buffer is immediately preceeded by the character we
are looking for and begins with one higher than that character,
and the buffer is misaligned, a match was errorneously detected
in the first character. Fix this by changing the way we prevent
matches before the buffer from being detected: instead of
removing the corresponding bit from the 0x80..80 mask, set the
LSB of bytes before the buffer after xoring with the character we
look for.
The bug only affects amd64 with ARCHLEVEL=scalar (cf. simd(7)).
The change comes at a 2% performance impact for short strings
if ARCHLEVEL is set to scalar. The default configuration is not
affected.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ strchrnul.scalar.0.out │ strchrnul.scalar.2.out │
│ sec/op │ sec/op vs base │
Short 57.89µ ± 2% 59.08µ ± 1% +2.07% (p=0.030 n=20)
Mid 19.24µ ± 0% 19.73µ ± 0% +2.53% (p=0.000 n=20)
Long 11.03µ ± 0% 11.03µ ± 0% ~ (p=0.547 n=20)
geomean 23.07µ 23.43µ +1.53%
│ strchrnul.scalar.0.out │ strchrnul.scalar.2.out │
│ B/s │ B/s vs base │
Short 2.011Gi ± 2% 1.970Gi ± 1% -2.02% (p=0.030 n=20)
Mid 6.049Gi ± 0% 5.900Gi ± 0% -2.47% (p=0.000 n=20)
Long 10.56Gi ± 0% 10.56Gi ± 0% ~ (p=0.547 n=20)
geomean 5.045Gi 4.969Gi -1.50%
MFC to: stable/14
MFC after: 3 days
Approved by: mjg (blanket, via IRC)
Sponsored by: The FreeBSD Foundation
Move the timerfd impelemntation from linux compat code to sys/kern. Use
it to implement the new system calls for timerfd. Add a hook to kern_tc
to allow timerfd to know when the system time has stepped. Add kqueue
support to timerfd. Adjust a few names to be less Linux centric.
RelNotes: YES
Reviewed by: markj (on irc), imp, kib (with reservations), jhb (slack)
Differential Revision: https://reviews.freebsd.org/D38459
Right now we have to zero-initialize most fields in the varius callers,
but this is a little error prone. Simplify it by zeroing it out upon
allocation instead, drop the other redundant initialization.
Reviewed by: markj
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41546
In 693f88c9da ("iconv_std: complete the //IGNORE support"), we
more completely implemented //IGNORE, which changed the semantics of
ci_discard_ilseq. DISCARD_ILSEQ semantics are supposed to match
//IGNORE, so we really can't do much about that particular
incompatibility. This broke c*rtomb and mbrtoc* handling of invalid
sequences, but it turns out they don't want DISCARD_ILSEQ semantics at
all; they really want the subset that we call
_CITRUS_ICONV_F_HIDE_INVALID.
This restores the exact flow in iconv_std to precisely how it happened
prior to 693f88c9da.
PR: 265871
Fixes: 693f88c9da ("iconv_std: complete the //IGNORE support")
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41513
This is an attempt at clean-room implementation of the Linux'
membarrier(2) syscall. For documentation, you would need to read
both membarrier(2) Linux man page, the comments in Linux
kernel/sched/membarrier.c implementation and possibly look at
actual uses.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32360
This changeset adds a baseline implementation of memcmp and bcmp
for amd64. The same code is used for both functions with conditional
code were the behaviour differs (we need more precise output for the
memcmp case).
FreeBSD documents that memcmp returns the difference between the
mismatching characters. Slightly faster code would be possible could
we relax this requirement to the ISO/IEC 9899:1999 requirement of
merely returning a negative/positive integer or zero.
Performance is better than bionic and glibc, except for long strings
were the two are 13% faster. This could be because they use SSE4
ptest which we cannot use in a baseline kernel.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
Differential Revision: https://reviews.freebsd.org/D41442
This commit adds a baseline implementation of stpcpy(3) for amd64.
It performs quite well in comparison to the previous scalar implementation
as well as agains bionic and glibc (though glibc is faster for very long
strings). Fiddle with the Makefile to also have strcpy(3) call into the
optimised stpcpy(3) code, fixing an oversight from D9841.
Sponsored by: The FreeBSD Foundation
Reviewed by: imp ngie emaste
Approved by: mjg kib
Fixes: D9841
Differential Revision: https://reviews.freebsd.org/D41349
pthread_getname_np needs to be provided by libc in order to import
jemalloc 5.3.0.
A stub implementation for libc pthread_getname_np() is added for
_pthread_stubs.c, which always reports empty name for the main thread.
Internal _pthread_getname_np() is not exported, but provided for libc
own use.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41461
Create a stdlib/malloc to hold the definition of the malloc interface
(e.g., the Symbol.map file) and make jemalloc a subdirectory. This will
make it easier to integrate alternative allocators such as snmalloc
while making it clear that the current jemalloc symbols are the FreeBSD
API/ABI (for better or worse).
Suggested by: jrtc27
Reviewed by: jrtc27, emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41457
All jemalloc sources are in contrib so don't look for them in the
jemalloc subdirectory.
Reviewed by: jrtc27, emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41481
There's a hierarchy here and we should use it.
Improves: cbeacb7c46
Reviewed by: jrtc27, jhb, emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41456
This likely documented where this file was copied, but the $FreeBSD$
tag was lost as soon as it was committed. Just remove it. Also remove
the one that looked like it was intended to track versions. That will
simplify the MFC.
Sponsored by: Netflix
These configuration headers were only guessed, but unfortunately not exactly
correctly. Therefore, re-generate them on real HW.
Generated on CA15, verified on CA9, CA7(with VFP lite) and on 32-bit ARMv9.
PR: 272229
Reported by: Robert Clausecker <fuz@FreeBSD.org>
MFC after: 2 weeks
Apparently there are applications that resolve dl_iterate_phdr from libc
and try to call the symbol. Our libc only provides stubs for dl* to
satisfy static linker or statically linked binaries, and is not prepared
to this situation.
Add a code to dso libc to find real dl_iterate_phdr and redirect the
call to it.
Reported by: yuri
PR: 272992
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Also use __func__ rather than hardcoding the function name. This code
now fits in 80 columns without splitting the log message.
Reviewed by: zlei
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39619
This performs very well. x86-64-v3 and x86-64-v4 kernels were written,
too, but performed worse than the baseline kernel on short strings.
These may be added at a future point in time if the performance issues
can be fixed.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ strlen_scalar.out │ strlen_baseline.out │
│ B/s │ B/s vs base │
Short 1.667Gi ± 1% 2.676Gi ± 1% +60.55% (p=0.000 n=20)
Mid 5.459Gi ± 1% 8.756Gi ± 1% +60.39% (p=0.000 n=20)
Long 15.34Gi ± 0% 52.27Gi ± 0% +240.64% (p=0.000 n=20)
geomean 5.188Gi 10.70Gi +106.24%
Sponsored by: The FreeBSD Foundation
Approved by: kib
Reviewed by: mjg jrtc27
Differential Revision: https://reviews.freebsd.org/D40693
Add a framework for selecting from one of multiple implementations
of a function based on amd64 architecture level (cf. amd64 SysV
ABI supplement).
Sponsored by: The FreeBSD Foundation
Approved by: kib
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D40693
Machine endianness is not very important in understanding the inet*
functions; the endianness of the VAX is especially so.
PR: 272728
Sponsored by: The FreeBSD Foundation
Extrapolate from the context what the intention for the rest of the
comment probably was -- that the C/POSIX (and now C.UTF-8) locales may
avoid an allocation and reuse a global table.
Reviewed by: bapt
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41087
bcmp() returned the number of remaining bytes when the main loop exits.
In case of a match, this is zero, else a positive integer. On systems
where SIZE_MAX > INT_MAX, the implicit conversion from size_t to int in
the return value may cause the number of remaining bytes to overflow,
becoming zero and falsely indicating a successful comparison.
Fix the bug by always returning 0 on equality, 1 otherwise.
PR: 272474
Approved by: emaste
Reviewed by: imp
MFC After: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41011
Gcc warns of infinite recursion if we use __builtin_ffs*() to
implement ffs*(). This is because gcc uses ffs() to implement
these on some platforms. Sidestep the warning by using
__builtin_ctz*() for these.
Sponsored by: FreeBSD Foundation
Reported by: jlduran@gmail.com, jhb
Fixes: ee8b0c43 (D40730)
Reviewed by: jhb, mhorne
Approved by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40966
Having the symbols exported by libc differ between i386 and amd64 lib32
is questionable. Since these files build just fine today, stop guarding
them with !defined(COMPAT_32BIT). Whether or not they work at run time
is a different matter, but an i386 jail would be similarly affected if
not, so that's not a problem with lib32.
Reviewed by: kib, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40937
Most architectures we support (except for riscv64) have instructions
to compute these functions very quickly. Replace old code with the
ffs and clz builtin functions, allowing clang to generate good code
for all architectures.
As a consequence, toss out arm and i386 ffs() implementations.
Sponsored by: FreeBSD Foundation
Approved by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40730
Also supply CFLAGS+=-fno-builtin to ensure our unit tests
actually test libc functions and not clang's builtins.
Sponsored by: FreeBSD Foundation
Approved by: kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40729
When libc switched to generation of logs as per RFC 5424,
that change broke application ability to insert specific process id
using ident[N] format, the feature existed for decades.
Some processes rely on it (including logger and syslogd).
Later the regression was fixed but the feature remained undocumented.
This change documents it.
MFC after: 1 week
The current code assumes running on big-endian, which causes issues with
e.g. strtod() as reported on https://github.com/ocaml/ocaml/pull/10837#issuecomment-1605346422
This is probably a leftover from when powerpc64le was introduced.
Approved by: jhibbits (on IRC)
to make __cxa_thread_call_dtors() operational for statically linked
binaries.
Noted by: andrew
Reviewed by: emaste, dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40748
- Correct the document title
- This function has an _np suffix
- acl_strip_np has a manpage, xref it
- RETURN VALUES should describe acl_is_trivial_np, not acl_get_tag_type
Sponsored by: Klara, Inc.
At a minimum, we need enough for the colllation format version string +
locale definition version string and a full collate_info definition,
rather than just the first two and a pointer.
Sponsored by: Klara, Inc.
The SPDX folks have obsoleted the BSD-2-Clause-NetBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
- Mention it in acl(3) as an available function, xref
- Mention it in acl_get_permset(3), as acl_get_perm_np(3) is a natural
follow-up to acl_get_permset(3)
Sponsored by: Klara, Inc.
A user may use a tool chain from a package or just use an existing
tool chain from a previous installation. There is no reason for this
to disable the installation of lib${LIB}_pic.a.
This also means we don't need to force MK_TOOLCHAIN=yes in lib/libc.
This reverts part of commit c0f5aeb032.
Reviewed by: jrtc27
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39917
As documented in listen.2 manual page, the kernel emits a LOG_DEBUG
syslog message if a socket listen queue overflows. For some appliances,
it may be desirable to change the priority to some higher value
like LOG_INFO while keeping other debugging suppressed.
OTOH there are cases when such overflows are normal and expected.
Then it may be desirable to suppress overflow logging altogether,
so that dmesg buffer is not flooded over long run.
In addition to existing sysctl kern.ipc.sooverinterval,
introduce new sysctl kern.ipc.sooverprio that defaults to 7 (LOG_DEBUG)
to preserve current behavior. It may be changed to any value
in a range of 0..7 for corresponding priority or to -1 to suppress logging.
Document it in the listen.2 manual page.
MFC after: 1 month
Some points for the future:
- libc is not the right place for sorting algorithms.
Probably libutil is better suited for this purpose or
a dedicated libsort. Should move all sorting algorithms
away from libc eventually.
- CheriBSD uses capabilities for memory access, and could
benefit from a standard memswap() function.
- Do something about qsort() in FreeBSD's libc like:
- Mark it deprecated on FreeBSD, as a first step,
due to missing limits on CPU time.
- Audit the use of qsort() in the FreeBSD base system
and consider swapping to other existing sorting
algorithms.
Discussed with: brooks@
Differential Revision: https://reviews.freebsd.org/D36493
This reverts commit a7469c9c0a.
This reverts commit 7d65a450cd.
This reverts commit 8dcf3a82c5.
If there are less than two elements avoid executing the first
sorting loop. No functional change intended.
Reviewed by: kib@
MFC after: 1 week
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D39691
When sorting, both the C11 standard (ISO/IEC 9899:2011, K.3.6.3.2) and
the ISO/IEC JTC1 SC22 WG14 N1172 standard, does not define objects of
zero size as undefined behaviour. However Microsoft's cpp-docs does.
Add proper checks for this. Found while working on bsort(3).
Reviewed by: kib@ and emaste@
MFC after: 1 week
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D39687
The bsort(3) algorithm works by swapping objects, similarly to qsort(3),
and does not require any significant amount of additional memory.
The bsort(3) algorithm doesn't suffer from the processing time issues
known the plague the qsort(3) family of algorithms, and is bounded by
a complexity of O(log2(N) * log2(N) * N), where N is the number of
elements in the sorting array. The additional complexity compared to
mergesort(3) is a fair tradeoff in situations where no memory may
be allocated.
The bsort(3) APIs are identical to those of qsort(3), allowing for
easy drop-in and testing.
The design of the bsort(3) algorithm allows for future parallell CPU
execution when sorting arrays. The current version of the bsort(3)
algorithm is single threaded. This is possible because fixed areas
of the sorting data is compared at a time, and can easily be divided
among different CPU's to sort large arrays faster.
Reviewed by: gbe@, delphij@, pauamma_gundo.com (manpages)
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D36493
For a process supervisor using the reaper API to track process subtrees,
it is very useful to know the state of the processes on the list.
Sponsored by: https://www.patreon.com/valpackett
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39585
by making it accept some open(2) flags. More precisely, only
O_CLOEXEC is supported, the flag is translated into the KQUEUE_CLOEXEC flag
for kqueuex(2), and O_NONBLOCK is silently ignored.
Reported and tested by: vishwin
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39377
There is no real need to close descriptors before a process exits, but
these close calls demonstrate by example that kqueue descriptors occupy
the same namespace as other file descriptors.
Reviewed by: fernape, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39376
memmem started as a GNU extension but is now widely available.
Reviewed by: mhorne (slightly earlier version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39337
There are FAT12 and FAT16 file systems, but FAT13 of was an
unintentional invention of mine ...
Reported by: Ravi Pokala <rpokala@freebsd.org>
MFC after: 1 month
This update implements tallying of free directory entries during
create, delete, or rename operations on FAT12 and FAT16 file systems.
Prior to this change, the total number of root directory entries
was reported as number of inodes, but 0 as the number of free
inodes, causing system health monitoring software to warn about
a suspected disk full issue.
The FAT12 and FAT16 file systems provide a limited number of
root directory entries, e.g. 512 on typical hard disk formats.
The valid range of values is 1 to 65535, but the msdosfs code
will effectively round up "odd" values to the next multiple of 16
(e.g. 513 would allow for 528 root directory entries).
This update implements tracking of directory entries during create,
delete, or rename operations, with initial values determined by
scanning the directory when the file system is mounted.
Total and free directory entries are reported in the f_files and
f_ffree elements of struct statfs, despite differences in semantics
of these values:
- There is no limit on the number of files and directories that can
be created on a FAT file system. Only the root directory of FAT12
and FAT16 file systems is limited, any number of files can still be
created in sub-directories, even when 0 free "inodes" are reported.
- A single file can require 1 to 21 directory entries, depending on
the character set, structure, and length of the name. The DOS 8.3
style file name takes up 1 entry, and if the name does not comply
with the syntax of a DOS 8.3 file name, 1 additional entry is used
for each 13 characters of the file name. Since all these entries
have to be contiguous, it is possible that a file or directory with
a long name can not be created, despite a sufficient total number of
free directory entries.
- Renaming a file can require more directory entries than currently
allocated to store its long name, which may prevent an in-place
update of the name if more entries are needed. This may cause a
rename operation to fail if no contiguous range of free entries for
the new name can be found.
- The volume label is stored in a directory entry. An empty FAT file
system with a volume label will therefore show 1 used "inode" in
df.
- The perceentage of free inodes shown in df or monitoring tools does
only represent the state of the root directory of a FAT12 or FAT16
file system. Neither does a reported value of 0% free inodes does
prevent files from being created in sub-directories, nor does a
value of 50% free inodes guarantee that even a single file with
a "long" name can be created in the root directory (if every other
directory entry is occupied and there are no 2 contiguous entries).
The statfs(2) and df(1) man pages have been updated with a notice
regarding the possibly different semantics of values reported as
total and free inodes for non-Unix file systems.
PR: 270053
Reported by: Ben Woods <woodsb02@freebsd.org>
Approved by: mckusick
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D38987
Fix newlocale() overwriting the locale name in collate object
when same instance was used for those locales, and querylocale()
reporting unexpected value for LC_COLLATE_MASK.
PR: 255646, 269375
Reviewed by: markj, bapt (previous version)
Differential Revision: https://reviews.freebsd.org/D30146
These were brought in by the libbind import, but these functions were
never actually implemented anywhere, only header declarations and symbol
map entries were imported.
Fixes: 046c3635cd ("Bring final version of libbind:")
Fixes: e45764721a ("Update our stub resolver to final version of ...")
Reported by: ld.lld 16 being --no-undefined-version by default
Sponsored by: https://www.patreon.com/valpackett
Reviewed by: emaste
Pull request: https://github.com/freebsd/freebsd-src/pull/700
Differential Revision: https://reviews.freebsd.org/D38407
- This function no longer disables interrupts
- MLINK to reboot.9
- The mentions of autoconfiguration is more about shutdown_nice(),
coming in the next commit.
- Describe the RB_* flags relevant to this function
- Describe behaviour when shutdown hooks fail the reset
- Describe expected execution contexts
- Add FF copyright
- xref panic(9)
- xref this page in reboot(2)
Reviewed by: markj
Discussed with: rpokala, Pau Amma <pauamma@gundo.com>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39133
It got disabled in 2003:
commit acb18acfec
Author: Poul-Henning Kamp <phk@FreeBSD.org>
Date: Sun Feb 23 18:09:05 2003 +0000
Bracket the kern.vnode sysctl in #ifdef notyet because it results
in massive locking issues on diskless systems.
It is also not clear that this sysctl is non-dangerous in its
requirements for locked down memory on large RAM systems.
There does not seem to be practical use for it and the disabled routine
does not work anyway.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D39127
Add mostly glibc and msl compatible secure_getenv. Return NULL if
issetugid() indicates the process is tainted, otherwise getenv(x). The
rational behind this is the fact that many Linux applications use this
function instead of getenv() as it's widely consider a, "best
practice".
Reviewed by: imp, mjg (feedback)
Pull Request: https://github.com/freebsd/freebsd-src/pull/686
Signed-off-by: Lucy Marsh <seafork@disroot.org>
The referenced symbols that provide init array boundaries are weak,
hidden, and undefined. The code that iterates over that arrays is not
used for the case when libc is compiled as dso.
This should fix linking with ld.bfd.
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
The current name was a historical curiosity that started when init array
support was added, and then the file appeared a convenient place for the
addition of the MI common code to csu. It is now referenced by name in
single place and the rename is easy, so do it.
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Do not call CPUID on each ireloc, instead call it once and cache
results, similar to how it is done on powerpc64.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220
Why? Most trivial point, it shaves around 600 bytes from the dynamic
binaries on amd64. Less trivial, the removed code is no longer part of
the ABI, and we can ship updates to it with libc updates. Right now most
of the csu is linked into the binaries and require us to do somewhat
tricky ABI compat when it needs to change. For instance, the init_array
change would be much simpler and does not require note tagging if we
have init calling code in libc.
This could be improved more, by splitting dynamic and static
initialization. For instance, &_DYNAMIC tests can be removed then.
Such change, nonetheless, would require building libc three times.
I left this for later, after this change stabilizes, if ever.
Reviewed by: markj
Discussed with: jrtc27 (some objections, see the review), imp
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220
Summary:
All cap_* system calls would fail when capability mode support is
not present.
MFC after: 2 weeks
Reviewed by: emaste, pauamma
Differential Revision: https://reviews.freebsd.org/D38976
The behavior is the same as in capability mode, it does not actually
return EINVAL for absolute lookups:
openat(AT_FDCWD,"/tmp/test",O_RDONLY|O_DIRECTORY,00) = 3 (0x3)
openat(3,"../../",O_RDONLY|0x800000,00) ERR#93 'Capabilities insufficient'
openat(3,"/etc/passwd",O_RDONLY|0x800000,00) ERR#93 'Capabilities insufficient'
Fixes: 1f305be43 ("Document {O,AT}_RESOLVE_BENEATH...")
Reviewed by: kib, pauamma (manpages), emaste
Sponsored by: https://www.patreon.com/valpackett
Pull Request: https://github.com/freebsd/freebsd-src/pull/680
Differential Revision: https://reviews.freebsd.org/D38675
Rephrase double negated sentences to improve readability
OpenBSD has done the same in the past to their man 3 daemon
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/671
- Be consistent with RFC references, so add a space after 'RFC'
- Add a LIBRARY section
- Use standard integer types in the SYNOPSIS section
Obtained from: DragonflyBSD
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D27548
For compatibility with glibc. The previous code would trigger a division
by zero in roundup() and terminate. Instead, just pass through to
malloc() for align == 0.
PR: 269688
Reviewed by: imp, mjg
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/655
profil(II) is in the scanned 3rd edition manual that we have. We don't
have the 3rd edition sources, nor do we have the 4th edition souces. We
have a mostly complete (missing pipes) 4th edition C rewrite where
profil system call number is reserved, but it's not implemented (it's in
the manx section for things that apeared to have been in 3rd edition but
weren't yet part of the reimplemented 4th edition). The 5th edition
sources we have do have it, however. For other items that have appeared
in earlier manuals, we've added the simple verbage to the manual and
relegated the rest of the data for that file to the commit message.
To allow to run a newer world on a pre-1400079 kernel a compat shims to
the sched_affinity functions has beed added.
Reported by: antoine
Tested by: antoine
Reviewed by: kib
Differential revision: https://reviews.freebsd.org/D38555
MFC after: 3 days
Use it instead of defining IN_RTLD by base sources that want P_OSREL_
defines in userspace, but are not rtld.
This allows to remove abuse of IN_RTLD from userspace.
Reviewed by: dchagin, markj, imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38585
Simplify the tests for 32-bit arm soft float support. For the files
included only on arm, drop the test entirely. For others, test
MACHINE_CPUARCH against arm.
No functional change intended. File lists appear the same before / after
the change.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38582
No need to check the mode again here; we know that `iop` wraps the
correct fd.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D37987
getopt_long(3) will not allow an `optind` setting of 0 to be bug-for-bug
compatible with the GNU implementation, as some software does rely on
it. Document it as a BUG, since it affects previous declarations of
compatibility with getopt(3).
Reviewed by: pauamma (markup)
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D37867
With GCC 4.2 out of the tree for a while now and no sign of it
returning, we don't really need to support older versions that don't
allow us to specify a ctor priority anymore.
Noticed by: mjg
This function has been around since 4.4BSD but was dropped upstream in 2020. This went unnoticed when tzcode was updated. Bring it back, but prepare for removing it before 14.0 is released.
PR: 269445
MFC after: 3 days
Reported by: val@packett.cool
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38445
Casting to int truncates size on some platforms, resulting swab not
copying all the data. Cast len to size_t to avoid right shifting a
signed value: we know here it's > 0, so we can safely cast it w/o losing
precision.
In addition, be more careful with signedness of char pointers and
temporaries. Downgrade tmp from unsigned long to unsigned char since
we're only reading and writing characters.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/516
While here, move notes about FreeBSD-specific functionality to the
COMPATIBILITY section, and document the ECAPMODE error for shm_open().
Reviewed by: pauamma, kib
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D38282
In preparation for a follow-up revision wherein kvmclock may export
timekeeping info to userspace even in the absence of AMDID_RDTSCP, fall
back to using rdtsc when rdtscp isn't available. This mimics
pvclock_read_time_info() in the kernel.
Reviewed by: kib
Tested by: Shrikanth R Kamath <kshrikanth@juniper.net>
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D38341
Remove the hard-coded dependency on HYPERV being only x86. Instead, 100%
rely on MK_HYPERV. It's always right (since it's marked BROKEN (so set
to "no") on architectures we don't support).
Sponsored by: Netflix
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D38306
Under Linux to sched_[g|s]etaffinity() functions the value returned from a call
to gettid(2) (thread id) can be passed in the argument pid. Specifying pid as 0
will set the attribute for the calling thread, and passing the value returned
from a call to getpid(2) (process id) will set the attribute for the main thread
of the thread group.
Native cpuset(2) family of system calls has "which" argument to determine how
the value of id argument is interpreted, i.e., CPU_WHICH_TID is used to pass
a thread id and CPU_WHICH_PID - to pass a process id.
For now native sched_[g|s]etaffinity() implementation is wrong as uses "which"
CPU_WHICH_PID to pass both (process and thread id) to the kernel. To fix this
adding a new "which" CPU_WHICH_TIDPID intended to handle both id's.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D38209
MFC after: 1 week
Cast char's through unsigned char before storing as an integer in
xdr_char(), this ensures that the encoded form is consistently not
sign-extended following Open Solaris's example.
Prior to this change, platforms with signed chars would sign extend
values with the high bit set but ones with unsigned chars would not
so 0xff would be stored as 0x000000ff on unsigned char platforms and
0xffffffff on signed char platforms. Decoding has the same
result for either form so this is a largely cosmetic change, but it
seems best to produce consistent output.
For more discussion, see https://github.com/openzfs/zfs/issues/14173
Reviewed by: mav, imp
Differential Revision: https://reviews.freebsd.org/D37992
* Replay 2010[acflm] which had been merged but not recorded.
* Merge 2010n.
* Reorganize (unsplit) the code to match the upstream layout.
* Merge 2022[cdefg].
MFC after: 1 week
Sponsored by: Klara, Inc.
These architectures fail to handle this special case, and will cause the
corresponding setjmp/_setjmp to return 0 rather than 1. Fix this and add
regression tests (also committed upstream).
PR: 268684
Reviewed by: arichardson, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29363
Do not cache PID for a process that does not fabricate it,
calls openlog() before forking and does not call exec() thereafter.
PR: 268666
Fixes: e9ae9fa937
Tested by: kp
MFC after: 3 days
- provide various missing MLINKS for library functions
- update various SEE ALSO section to include the
new linked manual pages
- add various definitions of new functions like isideogram_l(3)
- document COMPATIBILITY for some functions
- bump man page dates
Reviewed by: gbe, bcr
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/621
Differential Revision: https://reviews.freebsd.org/D37203
Reverting because of issue in Makefile.inc1 during native builds:
make[1]: “.../freebsd/Makefile.inc1" line 163: Unknown target aarch64:aarch64.
Since I only tested this patch with make universe on amd64, this issue wasn't caught.
This reverts commit 83bf6ab568.
On powerpc64, powerpc64le and riscv64 some software wrongly assumes that
it runs on powerpc or riscv (32-bit).
Differential revision: https://reviews.freebsd.org/D35962
Approved by: alfredo, imp
Without this patch, the code in the rpcbind client forces
the use of UDP. A comment notes that some rpcbind servers
only support UDP. This makes NFSv3 mounts to Azure servers
impossible, since they require use of TCP for rpcbind.
Since the comment is very old (imported from NetBSD in 2001)
and I do not believe any UDP only rpcbind servers will
still exist, this patch comments out the code that forces
use of UDP, so that NFSv3 mounts to Azure servers can work.
For an NFSv3 mount, the "udp" mount option will still
make mount_nfs use UDP for rpcbind so that can be used
as a workaround for any old NFSv3 server that only
supports rpcbind over UDP (if any such server still exists).
I asked if doing this change is appropriate on freebsd-fs@
and I only got one reply (off list) that supported doing
the change.
PR: 267301
MFC after: 1 month
Refer to sockets rather than processes, since one can have multiple
sockets in a load-balancing group within the same process.
MFC after: 1 week
Sponsored by: Modirum MDPay
Sponsored by: Klara, Inc.
Rework getaddrinfo(3) to return different error values for unresolvable
names (same as before, EAI_NONAME) and those without a requested addr
(EAI_ADDRFAMILY) when using DNS. This is implemented via an added
error in the nsswitch layer, NS_ADDRFAMILY, which is used only by
getaddrinfo(). The error is passed through nsdispatch(3), but that
routine has no changes to handle this error. The error originates in
the getaddrinfo DNS layer called via nsdispatch(), and is processed
by the search layer that calls nsdispatch().
While here, add a little style to returns near those that were
modified.
Reviewed in https://reviews.freebsd.org/D37139 with related changes.
Reviewed by: bz
MFC after: 1 month
gai_strerror.c still has messages for EAI_ADDRFAMILY and EAI_NODATA,
but not the man page. Re-add to the man page, and update comments
in the source. Document the errors that are not in RFC 3493 or
POSIX.
Reviewed in https://reviews.freebsd.org/D37139 with related changes.
Reviewed by: bz, pauamma
MFC after: 1 month
phantom@'s HDD crashed with the final version of strfmon.c, as explained
in 9d430a5991.
Now there are tests in place that cover these code paths.
Reviewed by: kib
PR: 267410
Github PR: #620
MFC after: 1 week
strfmon_l does not take fully into consideration the explicitly passed
locale to perform the formatting.
Parallel universe bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=19633
Obtained from: Darwin
Reviewed by: kib
PR: 267410
Github PR: #620
MFC after: 1 week
Attempt to test the correctness of strfmon_l(3).
Items marked with XXX represent an invalid output.
Obtained from: e7eba0044f
Reviewed by: kib
PR: 267410
Github PR: #620
MFC after: 1 week
Otherwise strfmon(3) could overflow the buffer.
Here is mostly done for correctness and illustrative purposes, as there
is no chance it could actually happen.
Reviewed by: kib
PR: 267410
Github PR: #620
MFC after: 1 week
There's only one value that specifies the number of digits after the
decimal point (oh, sorry, the "radix character") the other specifies the
number before...
While here, add a little more info on the effects of using the #n value.
Obtained from: d1dd1a0864
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
There is a bug when formatting two consecutive values using fixed-widths
and the values need padding. This was because the value of pad_size
was zeroed only every other time.
Format Before After
[%8n] [%8n] [ $123.45] [ $123.45] [ $123.45] [ $123.45]
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
Fix an edge case by printing the required space when, the currency
symbol succeeds the value, a space separates the sign from the value and
the sign position precedes the quantity and the currency symbol.
In other words:
n_cs_precedes = 0
n_sep_by_space = 2
n_sign_posn = 1
From The Open Group's localeconv[1]:
> When {p,n,int_p,int_n}_sep_by_space is 2:
> If the currency symbol and sign string are adjacent, a space separates
> them; otherwise, a space separates the sign string from the value.
Format Before After
[%n] [-123.45¤] [- 123.45¤]
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/localeconv.html
Obtained from: Darwin
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
Take into consideration the possibility of quantities enclosed by
parentheses when aligning.
Matches the examples from The Open Group's:
Format Before After
%(#5n [$ 123.45] [ $ 123.45 ] Use an alternative pos/neg style
[($ 123.45)] [($ 123.45)]
[$ 3,456.78] [ $ 3,456.78 ]
%!(#5n [ 123.45] [ 123.45 ] Disable the currency symbol
[( 123.45)] [( 123.45)]
[ 3,456.78] [ 3,456.78 ]
https://pubs.opengroup.org/onlinepubs/9699919799/functions/strfmon.html
SD5-XSH-ERN-29 is applied, updating the examples for %(#5n and %!(#5n.
Obtained from: Darwin
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
The international currency symbol (int_curr_symbol) has a mandatory
SPACE character as the last character.
Trim this space after reading it, otherwise this extra space will always
be printed when displaying the int_curr_symbol.
Fixes the output when the international currency format is selected
(%i).
Locale Format Before After
en_US.UTF-8 [%i] [USD 123.45] [USD123.45]
fr_FR.UTF-8 [%i] [123,45 EUR ] [123,45 EUR]
Note that the en_US.UTF-8 locale states that no space should be printed
between the currency symbol and the value (sep_by_space = 0).
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
Avoid an out-of-bounds access when trying to set the space_char using an
international currency format (%i) and the C/POSIX locale.
The current code tries to read the SPACE from int_curr_symbol[3]:
currency_symbol = strdup(lc->int_curr_symbol);
space_char = *(currency_symbol+3);
But on C/POSIX locales, int_curr_symbol is empty.
Three implementations have been examined: NetBSD[1], Darwin[2], and
Illumos[3]. Only NetBSD has fixed it[4].
Darwin and NetBSD also trim the mandatory final SPACE character after
reading it.
Locale Format Darwin/NetBSD FreeBSD/Illumos
en_US.UTF-8 [%i] [USD123.45] [USD 123.45]
fr_FR.UTF-8 [%i] [123,45 EUR] [123,45 EUR ]
This commit only fixes the out-of-bounds access.
[1]: https://github.com/NetBSD/src/blob/trunk/lib/libc/stdlib/strfmon.c
[2]: https://opensource.apple.com/source/Libc/Libc-1439.141.1/stdlib/NetBSD/strfmon.c.auto.html
[3]: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/locale/strfmon.c
[4]: 3d7b5d498a
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
Otherwise we do not fall back to sysctls if the auxv entries are not
defined by the kernel. Arguably this is not a bug since we do not
support newer libc running on an older kernel, but we can be a bit more
gentle for the benefit of Valgrind or any other software which
synthesizes the auxv for virtualization purposes.
Reported by: Paul Floyd <paulf2718@gmail.com>
MFC after: 1 week
Reviewed by: brooks, kib
Differential Revision: https://reviews.freebsd.org/D37036
This reverts commit 76e6e4d72f.
Several programs in the tree use -1 instead of INT_MAX to use
the maximum value. Thanks to Eugene Grosbein for pointing this
out.
Ensure that a negative backlog argument is handled as it if was 0.
Reviewed by: markj@, glebius@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D31821
This reverts commit 1c2be25f60.
kib@ pointed out that it is perfectly fine to write at arbitrary regular
file offsets. For example, in a 4K block size character device, geom
doesn't support writing / reading 515 byte blocks. The description is
perhaps not applicable to all EINVALs returned.
The read system call will return EINVAL if the current file offset is
not a multiple of the block size. This also applies to write(2). Add an
entry for EINVAL about this error to both man pages.
PR: 91149
Event: Aberdeen Hackathon 2022
Differential Revision: https://reviews.freebsd.org/D24617
Rather than not including it on all 64-bit platforms, just include it on
32-bit ones.
Reviewed by: imp, jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D36422
From enh at google.com via openbsd-tech mailing list via pfg@:
The existing test is wrong for LP64, where size_t has twice as many
relevant bits as int, not just one. (Found by inspection by
rprichard.)
