already complete.
Since 416 is an error code, any Content-Range header in the response
would refer to the error message, not the requested document, so
relying on the value of size when we know we got a 416 is wrong.
Instead, just verify that offset == 0 and assume that we've reached
the end of the document (if offset > 0, we did not request a range,
and the server is screwing with us). Note that we cannot distinguish
between reaching the end and going past it, but that is a flaw in the
protocol, not in the code, so we just have to assume that the caller
knows what it's doing. A smart caller would request an offset
slightly before what it believes is the end and compare the result to
what is already in the file.
PR: 212065
Reported by: mandree
MFC after: 3 weeks
Dan Krejsa reports a potential memory leak in an fts_build error case,
detected by Coverity. (It doesn't seem to show up in Coverity Scan, so I
don't have a CID to point to.)
I don't know whether it is actually possible to arrive in this case with a
non-empty 'head' list. The cost is low, though. One additional branch in a
terminal error case isn't the end of the world.
PR: 217125
Submitted by: Dan Krejsa <dan.krejsa at gmail.com>
This is being done as a precursor for work needed to annontate failing
testcases with clang 4.0+.
MFC after: 1 week
PR: 217528
Sponsored by: Dell EMC Isilon
sbuf_hexdump(9) should be linked to sbuf(9), not hexdump(3). Another
review will be posted to deduplicate the sbuf_hexdump reference in
in hexdump(3) or at the very least make the information less duplicative.
MFC after: 1 week
X-MFC with: r313437
Sponsored by: Dell EMC Isilon
Update libarchive to version 3.3.1 (and sync with latest vendor dist)
Notable vendor changes:
PR #501: improvements in ACL path handling
PR #724: fix hang when reading malformed cpio files
PR #864: fix out of bounds read with malformed GNU tar archives
Documentation, style, test suite improvements and typo fixes.
New options to bsdtar that enable or disable reading and/or writing of:
Access Control Lists (--acls, --no-acls)
Extended file flags (--fflags, --no-fflags)
Extended attributes (--xattrs, --no-xattrs)
Mac OS X metadata (Mac OS X only) (--mac-metadata, --no-mac-metadata)
MFC after: 2 weeks
4.0.0 (branches/release_40 296509). The release will follow soon.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.
Also note that as of 4.0.0, lld should be able to link the base system
on amd64 and aarch64. See the WITH_LLD_IS_LLD setting in src.conf(5).
Though please be aware that this is work in progress.
Release notes for llvm, clang and lld will be available here:
<http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/4.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/4.0.0/tools/lld/docs/ReleaseNotes.html>
Thanks to Ed Maste, Jan Beich, Antoine Brodin and Eric Fiselier for
their help.
Relnotes: yes
Exp-run: antoine
PR: 215969, 216008
MFC after: 1 month
MDSRCS it intended to allow assembly versions of funtions with C
implementations listed in MISRCS. The selection of the correct
machdep_ldis?.c for a given architecture does not follow this pattern
and the file should be added to SRCS directly.
Reviewed by: emaste, imp, jhb
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9841
- Remove .c files which duplicate entries in MISRCS.
- Use the same, less merge conflict prone style in all cases.
- Use MDSRCS for mips (.c and .S files both ended up in SRCS).
- Remove pointless sparc64 Makefile.inc.
- Remove uninformative foreign VCS ID entries.
Reviewed by: emaste, imp, jhb
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9841
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
Also mention <time.h> in sem_timedwait(3), because POSIX does,
and because the user will need it for clockid_t, struct timespec,
and TIMER_ABSTIME.
Reported by: bde
MFC after: 9 days
X-MFC with: r314179
Sponsored by: Dell EMC
fail in the Capability mode. Instead silently fallback to the syscall
method, which is done for example in the gettimeofday(2) function.
Reviewed by: kib
The conditional in do_buff_decode(..) after the while loop was accidentally
inverted. Only increment the pointer for fmt if it's not NUL.
MFC after: 2 weeks
X-MFC with: r314189
Reported by: pstef
Sponsored by: Dell EMC Isilon
This function allows the caller to specify the reference clock
and choose between absolute and relative mode. In relative mode,
the remaining time can be returned.
The API is similar to clock_nanosleep(3). Thanks to Ed Schouten
for that suggestion.
While I'm here, reduce the sleep time in the semaphore "child"
test to greatly reduce its runtime. Also add a reasonable timeout.
Reviewed by: ed (userland)
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D9656
"C++"', otherwise ld refuses to make the symbols global in the final
library. This causes the __int128-related symbols to go missing when
the library is stripped during installation.
Helpful hints: emaste
MFC after: 2 weeks
X-MFC-With: r314061
the same CXXABI verions as recent libstdc++.
Note that __int128 types are only available on arches where long long is
128 bit wide.
Noticed by: harti
MFC after: 2 weeks
When using libfetch in an application that drops privileges when fetching
like pkg(8) then user complain because the application does not read anymore
${HOME}/.netrc. Now a caller can prepare a fd to the said file and manually
assign it to the structure.
It is also a first step to allow to capsicumize libfetch applications
Reviewed by: allanjude, des
Approved by: des
Differential Revision: https://reviews.freebsd.org/D9678
Although fp[get][set]sticky() functions are obsolete, they are still
required for GNU fortran49 library.
MFC after: 2 months
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D9634
