#
215332ff |
| 14-Dec-2019 |
Conrad Meyer <cem@FreeBSD.org> |
cdefs: Add __deprecated(message) function attribute macro
The legacy version of GCC4 currently in base does not support the parameterized form of this function attribute, as recent introduced in std
cdefs: Add __deprecated(message) function attribute macro
The legacy version of GCC4 currently in base does not support the parameterized form of this function attribute, as recent introduced in stdlib.h (r355747).
As we have done for other function attributes with similar compatibility problems, add a version-compatibile definition in sys/cdefs.h. Note that Clang defines itself to be GCC 4, so one must check for __clang__ in addition to __GNUC__ version. On legacy GCC 4, the macro expands to just the __deprecated__ attribute; on modern GCC or Clang, the macro expands to the parameterized variant with the message.
Ignoring legacy or unsupported compilers, the macro is also beneficial in that it is a bit more ergonomic than the full __attribute__((__deprecated__())) boilerplate.
Reported by: CI (but not tinderbox); imp and others Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D22817
show more ...
|
#
c62ff280 |
| 14-Dec-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Deprecate sranddev(3) API
It serves no useful purpose and wasn't as popular as its equally meritless cousin, srandomdev(3).
Setting aside the problems with rand(3) in general, the problem with this
Deprecate sranddev(3) API
It serves no useful purpose and wasn't as popular as its equally meritless cousin, srandomdev(3).
Setting aside the problems with rand(3) in general, the problem with this interface is that the seed isn't shared with the caller (other than by attacking the output of the generator, which is trivial, but not a hallmark of pleasant API design). The (arguable) utility of rand(3) or random(3) is as a semi-fast simulation generator which produces consistent results from a given seed. These are mutually at odd. Furthermore, sometimes people got the mistaken impression that a high quality random seed meant a weak generator like rand(3) or random(3) could be used for things like cryptographic key generation. This is absolutely not so.
The API was never part of a standard and was not widely used in tree. Existing in-tree uses have all been removed.
Possible replacement in out of tree codebases:
char buf[3]; time_t t;
time(t); strftime(buf, sizeof(buf), "%S", gmtime(&t)); srand(atoi(buf));
Relnotes: yes
show more ...
|
Revision tags: release/12.1.0 |
|
#
11478453 |
| 20-Aug-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Vendor import of stripped libc++ trunk r366426 (just before the release_90 branch point):
https://llvm.org/svn/llvm-project/libcxx/trunk@366426
|
#
58df81b3 |
| 30-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @350426
Sponsored by: The FreeBSD Foundation
|
#
07657474 |
| 29-Jul-2019 |
Mark Johnston <markj@FreeBSD.org> |
Add mkostempsat(3).
This is a variant of mkostemps() which takes a directory descriptor and returns a descriptor for a tempfile relative to that directory. Unlike the other mktemp functions, mkoste
Add mkostempsat(3).
This is a variant of mkostemps() which takes a directory descriptor and returns a descriptor for a tempfile relative to that directory. Unlike the other mktemp functions, mkostempsat() can be used in capability mode.
Reviewed by: cem Discussed with: brooks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21031
show more ...
|
Revision tags: release/11.3.0, release/12.0.0 |
|
#
da2d1e9d |
| 29-Aug-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r338298 through r338391.
|
#
a29173be |
| 26-Aug-2018 |
Xin LI <delphij@FreeBSD.org> |
Remove arc4random_stir and arc4random_addrandom from stdlib.h. Users of arc4random(3) should never call them directly.
All ports tree usage was fixed as part of bug 230756.
Relnotes: yes Appr
Remove arc4random_stir and arc4random_addrandom from stdlib.h. Users of arc4random(3) should never call them directly.
All ports tree usage was fixed as part of bug 230756.
Relnotes: yes Approved by: re (marius), exp-run (bug 230756 by portmgr antoine)
show more ...
|
#
7847e041 |
| 24-Aug-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r338026 through r338297, and resolve conflicts.
|
#
c1e80940 |
| 19-Aug-2018 |
Xin LI <delphij@FreeBSD.org> |
Update userland arc4random() with OpenBSD's Chacha20 based arc4random().
ObsoleteFiles.inc:
Remove manual pages for arc4random_addrandom(3) and arc4random_stir(3).
contrib/ntp/lib/isc/
Update userland arc4random() with OpenBSD's Chacha20 based arc4random().
ObsoleteFiles.inc:
Remove manual pages for arc4random_addrandom(3) and arc4random_stir(3).
contrib/ntp/lib/isc/random.c: contrib/ntp/sntp/libevent/evutil_rand.c:
Eliminate in-tree usage of arc4random_addrandom().
crypto/heimdal/lib/roken/rand.c: crypto/openssh/config.h:
Eliminate in-tree usage of arc4random_stir().
include/stdlib.h:
Remove arc4random_stir() and arc4random_addrandom() prototypes, provide temporary shims for transistion period.
lib/libc/gen/Makefile.inc:
Hook arc4random-compat.c to build, add hint for Chacha20 source for kernel, and remove arc4random_addrandom(3) and arc4random_stir(3) links.
lib/libc/gen/arc4random.c:
Adopt OpenBSD arc4random.c,v 1.54 with bare minimum changes, use the sys/crypto/chacha20 implementation of keystream.
lib/libc/gen/Symbol.map:
Remove arc4random_stir and arc4random_addrandom interfaces.
lib/libc/gen/arc4random.h:
Adopt OpenBSD arc4random.h,v 1.4 but provide _ARC4_LOCK of our own.
lib/libc/gen/arc4random.3:
Adopt OpenBSD arc4random.3,v 1.35 but keep FreeBSD r114444 and r118247.
lib/libc/gen/arc4random-compat.c:
Compatibility shims for arc4random_stir and arc4random_addrandom functions to preserve ABI. Log once when called but do nothing otherwise.
lib/libc/gen/getentropy.c: lib/libc/include/libc_private.h:
Fold __arc4_sysctl into getentropy.c (renamed to arnd_sysctl). Remove from libc_private.h as a result.
sys/crypto/chacha20/chacha.c: sys/crypto/chacha20/chacha.h:
Make it possible to use the kernel implementation in libc.
PR: 182610 Reviewed by: cem, markm Obtained from: OpenBSD Relnotes: yes Differential Revision: https://reviews.freebsd.org/D16760
show more ...
|
Revision tags: release/11.2.0 |
|
#
b8d1747e |
| 22-Jan-2018 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
Use the __alloc_size2 attribute where relevant.
This follows the documented use in GCC. It is basically only relevant for calloc(3), reallocarray(3) and mallocarray(9).
Suggested by: Mark Millard
Use the __alloc_size2 attribute where relevant.
This follows the documented use in GCC. It is basically only relevant for calloc(3), reallocarray(3) and mallocarray(9).
Suggested by: Mark Millard
Reference: https://docs.freebsd.org/cgi/mid.cgi?9DE674C6-EAA3-4E8A-906F-446E74D82FC4
show more ...
|
#
c79126f2 |
| 12-Jan-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r327624 through r327885.
|
#
dd5edb11 |
| 09-Jan-2018 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
Use the __result_use_check attribute also for reallocf(3).
The GCC attribute causes a warning to be emitted if a caller of the function with this attribute does not use its return value. Unlike the
Use the __result_use_check attribute also for reallocf(3).
The GCC attribute causes a warning to be emitted if a caller of the function with this attribute does not use its return value. Unlike the traditional realloc, with reallocf(3) we don't have to check for NULL values but we still have to make sure the result is used.
MFC after: 3 days
show more ...
|
#
54b4b13c |
| 24-Dec-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r326936 through r327149.
|
#
16545cf5 |
| 23-Dec-2017 |
Mariusz Zaborski <oshogbo@FreeBSD.org> |
Introduce the daemonfd function.
The daemonfd function is equivalent to the daemon(3) function expect that arguments are descriptors. For example dhclient(8) which is sandboxed is unable to open /de
Introduce the daemonfd function.
The daemonfd function is equivalent to the daemon(3) function expect that arguments are descriptors. For example dhclient(8) which is sandboxed is unable to open /dev/null to close stdio instead it's allows to fail daemon(3) function to close the descriptors and then do it explicit in code. Instead of such hacks we can use now daemonfd.
This API can be also helpful to migrate system to platforms like CheriBSD.
Reviewed by: brooks@, bcr@, jilles@ (earlier version) Differential Revision: https://reviews.freebsd.org/D13433
show more ...
|
#
82725ba9 |
| 23-Nov-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r325999 through r326131.
|
#
383f241d |
| 23-Nov-2017 |
Konstantin Belousov <kib@FreeBSD.org> |
Remove lint support from system headers and MD x86 headers.
Reviewed by: dim, jhb Discussed with: imp Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D13156
|
#
2321c474 |
| 20-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
include: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier
include: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point.
show more ...
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
7582e393 |
| 16-May-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Vendor import of libc++ trunk r303197: https://llvm.org/svn/llvm-project/libcxx/trunk@303197
|
#
9851b340 |
| 30-Mar-2017 |
Konstantin Belousov <kib@FreeBSD.org> |
Implement the memset_s(3) function as specified by the C11 ISO/IEC 9899:2011 Appendix K 3.7.4.1.
Other needed supporting types, defines and constraint_handler infrastructure is added as specified in
Implement the memset_s(3) function as specified by the C11 ISO/IEC 9899:2011 Appendix K 3.7.4.1.
Other needed supporting types, defines and constraint_handler infrastructure is added as specified in the C11 spec.
Submitted by: Tom Rix <trix@juniper.net> Sponsored by: Juniper Networks Discussed with: ed MFC after: 3 weeks Differential revision: https://reviews.freebsd.org/D9903 Differential revision: https://reviews.freebsd.org/D10161
show more ...
|
#
a3906ca5 |
| 17-Feb-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r313644 through r313895.
|
#
10723054 |
| 16-Feb-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
Remove outdated claim.
Despite wishful thinking the removal of these old function hasn't happened yet.
MFC after: 3 days
|
#
9b3ece1c |
| 04-Feb-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r313243
|
#
65575c14 |
| 29-Jan-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r312894 through r312967.
|
#
649702c5 |
| 28-Jan-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
Make use of clang nullability attributes.
Replace uses of the GCC __nonnull__ attribute with the clang nullability qualifiers. The replacement should be transparent for clang developers as the new q
Make use of clang nullability attributes.
Replace uses of the GCC __nonnull__ attribute with the clang nullability qualifiers. The replacement should be transparent for clang developers as the new qualifiers will produce the same warnings and will be useful for static checkers but will not cause aggressive optimizations.
GCC will not produce such warnings and developers will have to use upgraded GCC ports built with the system headers from r312538.
Hinted by: Apple's Libc-1158.20.4, Bionic libc MFC after: 11.1 Release
Differential Revision: https://reviews.freebsd.org/D9004
show more ...
|
#
f1b298ad |
| 01-Jan-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
Remove some uses of the GCC __nonnull() attribute.
While the checks are considered useful, the attribute does dangerous optimizations, removing NULL checks where they can be needed. Remove the uses
Remove some uses of the GCC __nonnull() attribute.
While the checks are considered useful, the attribute does dangerous optimizations, removing NULL checks where they can be needed. Remove the uses of this attribute introduced in r281130: the changes were inspired on Google's bionic where this attribute is not used anymore.
The __nonnull() attribute will be deprecrated from our headers and replaced with the Clang _Nonnull qualifier in the future.
MFC after: 3 days
show more ...
|