build can break when different source files create the same target
files (case-insensitivity speaking). This is the case for object
files compiled with -fpic and shared libraries. The former uses
an extension of ".So", and the latter an extension ".so". Rename
shared object files from *.So to *.pico to match what NetBSD does.
See also r305855
MFC after: 1 month
Sponsored by: Bracket Computing
Differential Revision: https://reviews.freebsd.org/D7906
This helps to ensure we will not lose SIGINT sent by parent to child.
Reviewed by: sbruno, ngie
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D7892
2) Implememt %u for GNU compatibility.
3) Don't forget to advance buf for %w/%u.
4) Fail with incomplete week (week 0) request and no such week in the
year.
5) Fix yday formula when Sunday requested and the week started from Monday.
6) Fail with impossible yday for incomplete week (week 0) and direct %w/%u
request.
7) Shift yday/wday to the first day of the year, if incomplete week
(week 0) requested and no %w/%u used.
MFC after: 7 days
have been added as some don't seem to be improvements over the libc C
implementation.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
it to lib/libc/tests/sys/Makefile [*]
Even though make -VPACKAGE and make -n install seem to do the right thing,
the effects are a bit different, depending on the build host.
MFC after: 1 week
Obtained from: HardenedBSD (af602f0db) [*]
Reported by: Oliver Pinter <oliver.pinter@hardenedbsd.org> [*]
Sponsored by: Dell EMC Isilon
It turns out that the path normalization that our brand new copy of
dirname(3) does is actually not allowed by the draft version of the
upcoming version of POSIX. It has to behave identically to the
dirname(1) utility.
This change replaces our new dirname(3) implementation by yet another
version that doesn't implement the path normalization logic; it merely
looks for the end of the directory name and overwrites that with a null
byte.
More details: See note #3370 at http://austingroupbugs.net/view.php?id=1073
PR: 212193
Reviewed by: emaste, jilles
Differential Revision: https://reviews.freebsd.org/D7790
needlessly
This is already being done by bsd.test.mk
The other subdirectory Makefiles were intentionally left alone
MFC after: 1 week
Sponsored by: Dell EMC Isilon
- Use _Bool to not require userspace to include stdbool.h.
- Make extattr.h usable without vnode_if.h.
- Follow i_ump to get cdev pointer.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
build can break when different source files create the same object
files (case-insensitivity speaking). This is the case for _Exit.c
and _exit.s. Compile _Exit.c as C99_Exit.c
Reviewed by: sjg@
MFC after: completion
Sponsored by: Bracket Computing
Differential Revision: https://reviews.freebsd.org/D7893
Sync libarchive with vendor including important security fixes.
Issues fixed (FreeBSD):
PR #778: ACL error handling
Issue #745: Symlink check prefix optimization is too aggressive
Issue #746: Hard links with data can evade sandboxing restrictions
This update fixes the vulnerability #3 and vulnerability #4 as reported in
"non-cryptanalytic attacks against FreeBSD update components".
https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f
Fix for vulnerability #2 has already been merged in r304989.
MFC after: 1 week
Security: http://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f
libifconfig is still experimental and under active development.
To avoid making any ABI promises, mark the library as private
Suggested by: bapt
Reviewed by: kp
Previously the flag returned by cap_getmode was not described explicitly
in the man page.
Reviewed by: wblock
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7822
The initial value of NOASM is nearly the same in all cases and the
initial value of PSEUDO is the same in all cases so reduce duplication
(and hopefully, future merge conflicts) by machine independent defaults.
Also document the PSEUDO variable.
Reviewed by: jhb, kib
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D7820
Sync libarchive with vendor
Vendor issues fixed:
PR #777: Multiple bugfixes for setup_acls()
This includes a bugfix for a bug that caused ACLs not to be read properly
for files and directories inside subdirectories and as a result not being
stored or being incorrectly stored in tar archives.
MFC after: 3 days
when the first mb sequence is incomplete and there are not enougn chars in
the read buffer. ws[-1] may lead to memory faults or false results, in
case the memory here contains '\n'.
2) Fix EOF checking I mess in my previos r305406 commit.
MFC after: 3 days
Also switch from BSD 3-clause to 2-clause license where possible, and
consolidate duplicate 3-clause license into one.
Submitted by: Marie Helene Kvello-Aune <marieheleneka@gmail.com>
Reviewed by: cem, kp
Differential Revision: https://reviews.freebsd.org/D7764
the build on i386. Leave them in the source tree for regression tests.
The asm functions were always much less accurate (by a factor of more
than 10**18 in the worst case). They were faster on old CPUs. But
with each new generation of CPUs they get relatively slower. The
double precision C version's average advantage is about a factor of 2
on Haswell.
The asm functions were already intentionally avoided in float and long
double precision on i386 and in all precisions on amd64. Float
precision and amd64 give larger advantages to the C version. The long
double precision C code and compilers' understanding of long double
precision are not so good, so the i387 is still slightly faster for
long double precision, except for the unimportant subcase of huge args
where the sub-optimal C code now somehow beats the i387 by about a
factor of 2.
versions of fmodf() amd fmodl() on i387.
fmod is similar to remainder, and the C versions are 3 to 9 times
slower than the asm versions on x86 for both, but we had the strange
mixture of all 6 variants of remainder in asm and only 1 of 6
variants of fmod in asm.
this library. Sticking to 'libifconfig' (and 'ifconfig_' as function prefix)
should reduce chances of namespace collisions, make it more clear what the
library does, and be more in line with existing libraries.
Submitted by: Marie Helene Kvello-Aune <marieheleneka@gmail.com>
Differential Revision: https://reviews.freebsd.org/D7742
Reviewed by: cem, kp
ISOCHRONOUS USB transfers. Make sure enough length and buffer pointers
are allocated when setting up the libusb transfer structure to support
the maximum number of frames the kernel can handle.
MFC after: 1 week
sequence near EOF), so we can't just check for
(wc == WEOF && !__sfeof(fp)) and must relay on __sferror(fp) with
__SERR clearing/restoring.
MFC after: 7 days
Capture executable names for CC, CPP, CXX (assumed to be the
first non-CCACHE_BIN word).
This change strips out all of the cross-compiler arguments, (-target,
-B, etc), added to ${CC}, etc via ${CROSSENV} in Makefile.inc1, so it
doesn't infect the build and subsequently the test.
Add comments noting why this logic is being added, and why the logic in
r305041 was necessary/what it was trying to achieve.
This is required after recent changes made to the toolchain to always
specify --sysroot, -target, -B, etc with clang in buildworld (presumably
r304681).
Reviewed by: rodrigc (earlier version)
Reported by: Jenkins (FreeBSD_HEAD job from 559+)
MFC after: 12 days
X-MFC with: r304681, r305041
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7732
In existing implementations including FreeBSD, there is no reason to use
readdir_r() in the common case where potentially multiple threads each list
their own directory. Code using readdir() is simpler.
What's more, lthough readdir_r() can safely be used on FreeBSD because
NAME_MAX is forced to 255, it cannot be used safely on systems where
{NAME_MAX} is not fixed. As a concrete example, FAT/NTFS filenames can be up
to 255 UTF-16 code units long, which can be up to 765 UTF-8 bytes.
Deprecating readdir_r() in POSIX has been proposed in
http://www.austingroupbugs.net/view.php?id=696
and glibc wants to deprecate it as well.
Reviewed by: ed, wblock
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D7678
