FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F14.4.0 2023-11-27T04:20:09Z 2023-11-27T04:20:09Z Warner Losh imp@FreeBSD.org 2023-11-01T22:43:37Z urn:sha1:4025b5b527c870cf095ac9531764f4e4d3feaec2 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 (cherry picked from commit 559a218c9b257775fb249b67945fe4a05b7a6b9f) 2023-08-16T17:54:42Z Warner Losh imp@FreeBSD.org 2023-08-16T17:54:42Z urn:sha1:1d386b48a555f61cb7325543adbbb5c3f3407a66 Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ 2021-07-21T15:32:22Z Alexander Motin mav@FreeBSD.org 2021-07-21T15:25:46Z urn:sha1:3a57f08b5042f15bb8ffb2fcce99d082d225d4cf Before this patch there was a chance for thread that called rand(3) slightly later to see rand3_state already allocated, but not yet initialized. While this API is not expected to be thread-safe, it is not expected to crash. ztest on 64-thread system reproduced it reliably for me. Submitted by: avg@ MFC after: 1 month 2021-07-21T15:32:22Z Alexander Motin mav@FreeBSD.org 2021-07-21T14:50:14Z urn:sha1:2ae65d449fecf22f493ce2dcb9e293bb8d95c8ef It is going to be reimplemented with _once(). This reverts commit 28d70deaafa62c5d1602de5272c0aad0fcca8aff. MFC after: 1 month 2021-07-20T17:30:28Z Alexander Motin mav@FreeBSD.org 2021-07-20T17:15:08Z urn:sha1:28d70deaafa62c5d1602de5272c0aad0fcca8aff Before this patch there was a chance for thread that called rand(3) slightly later to see rand3_state already allocated, but not yet initialized. While this API is not expected to be thread-safe, it is not expected to crash. ztest on 64-thread system reproduced it reliably for me. MFC after: 1 month 2020-02-01T20:33:23Z Conrad Meyer cem@FreeBSD.org 2020-02-01T20:33:23Z urn:sha1:672e12255da9b211d5318889ed9441ffc63c9f30 rand(3)'s standard C API is extremely limiting, but we can do better than the historical 32-bit state Park-Miller LCG we've shipped since 2001: r73156. The justification provided at the time for not using random(3) was that rand_r(3) could not be made to use the same algorithm. That is still true. However, the irrelevance of rand_r(3) is increasingly obvious. Since that time, POSIX has marked the interface obsolescent. rand_r(3) never became part of the standard C library. If not for API compatibility reasons, I would just remove rand_r(3) entirely. So, I do not believe it is a problem for rand_r(3) and rand(3) to diverge. The 12 ABI is maintained with compatibility definitions, but this revision does subtly change the API of rand(3). The sequences of pseudorandom numbers produced in programs built against new versions of libc will differ from programs built against prior versions of libc. Reviewed by: kevans, markm MFC after: no Relnotes: yes Differential Revision: https://reviews.freebsd.org/D23290 2020-01-20T23:43:47Z Conrad Meyer cem@FreeBSD.org 2020-01-20T23:43:47Z urn:sha1:6ee287b9c26180b480620ddad1a11b006adc9d49 2019-12-14T08:28:10Z Conrad Meyer cem@FreeBSD.org 2019-12-14T08:28:10Z urn:sha1:c62ff2800ba9e4b6e851ae71b1696b28920854b9 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 2017-11-20T19:49:47Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-20T19:49:47Z urn:sha1:8a16b7a18f5d0b031f09832fd7752fba717e2a97 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. 2016-05-29T13:57:06Z Andrey A. Chernov ache@FreeBSD.org 2016-05-29T13:57:06Z urn:sha1:44f87738345ccf7da818c80cefac28916928bebb reading hard. 2) Instead of doing range transformation in each and every function here, do it single time directly in do_rand(). One "mod" operation overhead is not a big deal, but the code looks nicer and possible future functions additions or PRNG change do not miss range transformations neither have unneeded ones. 3) Use POSIX argument types for visible functions (cosmetic). MFC after: 1 week