aboutsummaryrefslogtreecommitdiff
path: root/lib/libc/stdlib
Commit message (Collapse)AuthorAgeFilesLines
* qsort.c: prevent undefined behaviorStefan Eßer2022-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mark Milliard has detected a case of undefined behavior with the LLVM UBSAN. The mandoc program called qsort with a==NULL and n==0, which is allowed by the POSIX standard. The qsort() in FreeBSD did not attempt to perform any accesses using the passed pointer for n==0, but it did add an offset to the pointer value, which is undefined behavior in case of a NULL pointer. This operation has no adverse effects on any achitecture supported by FreeBSD, but could be caught in more strict environments. After some discussion in the freebsd-current mail list, it was concluded that the case of a==NULL and n!=0 should still be caught by UBSAN (or cause a program abort due to an illegal access) in order to not hide errors in programs incorrectly invoking qsort(). Only the the case of a==NULL and n==0 should be fixed to not perform the undefined operation on a NULL pointer. This commit makes qsort() exit before reaching the point of potentially undefined behvior for the case n==0, but does not test the value of a, since the result will not depend on whether this pointer is NULL or an actual pointer to an array if n==0. The issue found by Mark Milliard in the whatis command has been reported to the upstream (OpenBSD) and has already been patched there. (cherry picked from commit d106f982a54cd299671ccad58bc456138a22ae7b)
* Fix null pointer subtraction in mergesort()Dimitry Andric2021-08-311-5/+1
| | | | | | | | | | | | | | | | | Clang 13 produces the following warning for this function: lib/libc/stdlib/merge.c:137:41: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] if (!(size % ISIZE) && !(((char *)base - (char *)0) % ISIZE)) ^ ~~~~~~~~~ This is meant to check whether the size and base parameters are aligned to the size of an int, so use our __is_aligned() macro instead. Also remove the comment that indicated this "stupid subtraction" was done to pacify some ancient and unknown Cray compiler, and which has been there since the BSD 4.4 Lite Lib Sources were imported. (cherry picked from commit 4e5d32a445f90d37966cd6de571978551654e3f3)
* Fix race between first rand(3) calls with _once().Alexander Motin2021-08-191-4/+5
| | | | | | | | | | | | | 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 (cherry picked from commit 3a57f08b5042f15bb8ffb2fcce99d082d225d4cf)
* _Exit(3): document implementationKonstantin Belousov2021-08-121-6/+14
| | | | (cherry picked from commit ee62fb2e1e14eab35d4e4e92535bcac9fc91eeb8)
* libc/qsort: Don't allow interposing recursive callsAlex Richardson2021-03-171-50/+48
| | | | | | | | | | | | | | | | | | | This causes problems when using ASAN with a runtime older than 12.0 since the intercept does not expect qsort() to call itself using an interposable function call. This results in infinite recursion and stack exhaustion when a binary compiled with -fsanitize=address calls qsort. See also https://bugs.llvm.org/show_bug.cgi?id=46832 and https://reviews.llvm.org/D84509 (ASAN runtime patch). To prevent this problem, this patch uses a static helper function for the actual qsort() implementation. This prevents interposition and allows for direct calls. As a nice side-effect, we can also move the qsort_s checks to the top-level function and out of the recursive calls. Reviewed By: kib Differential Revision: https://reviews.freebsd.org/D28133 (cherry picked from commit cbcfe28f9d5f975f97b7fb4a0d72bc9780eb0c46)
* libc: Fix null pointer arithmetic warning in mergesortAlex Richardson2021-01-201-4/+2
| | | | | | | | | This file has other questionable code and "optimizations" (such as copying one int at a time) that are probably no longer useful, so it might make sense to replace it with a different implementation at some point. Reviewed By: jhb Differential Revision: https://reviews.freebsd.org/D28134
* getopt: Fix conversion from string-literal to non-const char *Alex Richardson2021-01-192-4/+3
| | | | | | Define a non-const static char EMSG[] = "" to avoid having to add __DECONST() to all uses of EMSG. Also make current_dash a const char * to fix this warning.
* libc: Fix most issues reported by mandocGordon Bergling2020-12-191-1/+1
| | | | | | | | | | | | | | - varios "new sentence, new line" warnings - varios "sections out of conventional order" warnings - varios "unusual Xr order" warnings - varios "missing section argument" warnings - varios "no blank before trailing delimiter" warnings - varios "normalizing date format" warnings MFC after: 1 month Notes: svn path=/head/; revision=368817
* Further refinements of ptsname_r(3) interface:Xin LI2020-10-202-6/+8
| | | | | | | | | | | | | | | | | - Hide ptsname_r under __BSD_VISIBLE for now as the specification is not finalized at this time. - Keep Symbol.map sorted. - Avoid the interposing of ptsname_r(3) from an user application from breaking ptsname(3) by making the implementation a static method and call the static function from ptsname(3) instead. Reported by: kib Reviewed by: kib, jilles MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D26845 Notes: svn path=/head/; revision=366866
* Implement ptsname_r.Xin LI2020-10-174-16/+66
| | | | | | | | | | MFC after: 2 weeks PR: 250062 Reviewed by: jilles, 0mp, Ray <i maskray me> Differential Revision: https://reviews.freebsd.org/D26647 Notes: svn path=/head/; revision=366781
* libc: typo fix (s/involes/involves)Kyle Evans2020-10-161-1/+1
| | | | | | | | Reported by: Masahiko Sawada via twitter MFC after: 3 days Notes: svn path=/head/; revision=366770
* Follow-up r365371 by removing sentences which indicate the state of theDimitry Andric2020-09-061-1/+1
| | | | | | | | | | | | | MK_MALLOC_PRODUCTION option on -CURRENT. Also, for the sake of backwards compatibility, support the old way of enabling 'production malloc', e.g. by adding a define in make.conf(5). MFC after: 1 week X-MFC-With: r365371 Notes: svn path=/head/; revision=365373
* Turn MALLOC_PRODUCTION into a regular src.conf(5) optionDimitry Andric2020-09-051-1/+1
| | | | | | | | | | | | | | | | | | For historical reasons, defining MALLOC_PRODUCTION in /etc/make.conf has been used to turn off potentially expensive debug checks and statistics gathering in the implementation of malloc(3). It seems more consistent to turn this into a regular src.conf(5) option, e.g. WITH_MALLOC_PRODUCTION / WITHOUT_MALLOC_PRODUCTION. This can then be toggled similar to any other source build option, and turned on or off by default for e.g. stable branches. Reviewed by: imp, #manpages MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D26337 Notes: svn path=/head/; revision=365371
* Compute the correct size of the string to move forward.John Baldwin2020-09-021-1/+1
| | | | | | | | | | | | | | | | | | | | Previously this was counting the amount of spare room at the start of the buffer that the string needed to move forward and passing that as the number of bytes to copy to memmove rather than the length of the string to be copied. In the strfmon test in the test suite this caused the memmove to overflow the allocated buffer by one byte which CHERI caught. Reported by: CHERI Reviewed by: kevans Obtained from: CheriBSD MFC after: 1 week Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D26280 Notes: svn path=/head/; revision=365276
* Fix a typo: argments -> argumentsBenedict Reuschling2020-05-191-1/+1
| | | | | | | | | PR: 243294 Submitted by: Igor Ostapenko MFC after: 5 days Notes: svn path=/head/; revision=361249
* Update jemalloc to version 5.2.1Eric van Gyzen2020-04-231-2/+3
| | | | | | | | | | | | | | | | | | | Revert r354606 to restore r354605. Apply one line from jemalloc commit d01b425e5d1e1 in hash_x86_128() to fix the build with gcc, which only allows a fallthrough attribute to appear before a case or default label. Submitted by: jasone in r354605 Discussed with: jasone Reviewed by: bdrewery MFC after: never, due to gcc 4.2.1 Relnotes: yes Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D24522 Notes: svn path=/head/; revision=360233
* exit(3): Add HISTORY sectionSergio Carlavilla Delgado2020-04-101-1/+6
| | | | | | | | | | PR: 240259 Submitted by: Gordon Bergling Obtained from: OpenBSD Differential Revision: https://reviews.freebsd.org/D24146 Notes: svn path=/head/; revision=359772
* Note some functions that appeared in First Edition UnixWarner Losh2020-04-012-2/+12
| | | | | | | | | These functions first appeared in the First Edition of Unix (or earlier in the pdp-7 version). Just claim 1st Edition for all this. The pdp-7 code is too fragmented at this point to extend history that far back. Notes: svn path=/head/; revision=359547
* vfs: add realpathat syscallMateusz Guzik2020-02-201-1/+10
| | | | | | | | | | | | | | | | | | realpath(3) is used a lot e.g., by clang and is a major source of getcwd and fstatat calls. This can be done more efficiently in the kernel. This works by performing a regular lookup while saving the name and found parent directory. If the terminal vnode is a directory we can resolve it using usual means. Otherwise we can use the name saved by lookup and resolve the parent. See the review for sample syscall counts. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D23574 Notes: svn path=/head/; revision=358172
* rand(3): Replace implementation with one backed by random(3) algorithmConrad Meyer2020-02-016-85/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=357382
* random(3): Abstract routines into _r versions on explicit stateConrad Meyer2020-01-242-79/+163
| | | | | | | | | | | | | | | | | | | | | The existing APIs simply pass the implicit global state to the _r variants. No functional change. Note that these routines are not exported from libc and are not intended to be exported. If someone wished to export them from libc (which I would discourage), they should first be modified to match the inconsistent parameter type / order of the glibc public interfaces of the same names. I know Ravi will ask, so: the eventual goal of this series is to replace rand(3) with the implementation from random(3) (D23290). However, I'd like to wait a bit longer on that one to see if more feedback emerges. Reviewed by: kevans, markm Differential Revision: https://reviews.freebsd.org/D23289 Notes: svn path=/head/; revision=357066
* random(3): Abstract state into a single context objectConrad Meyer2020-01-241-99/+132
| | | | | | | | | | No functional change. Reviewed by: kevans, markm Differential Revision: https://reviews.freebsd.org/D23288 Notes: svn path=/head/; revision=357065
* random.3: Some minor improvements to wording/clarityConrad Meyer2020-01-201-44/+37
| | | | Notes: svn path=/head/; revision=356935
* libc: Delete unused rand.c ifdef TEST codeConrad Meyer2020-01-201-34/+0
| | | | Notes: svn path=/head/; revision=356934
* qsort.3: Bump Dd and note that Annex K is optionalConrad Meyer2020-01-201-1/+8
| | | | Notes: svn path=/head/; revision=356922
* Add qsort_s(3). Apart from the constraints, it also makes it easierEdward Tomasz Napierala2020-01-205-10/+127
| | | | | | | | | | | | | to port software written for Linux variant of qsort_r(3). Reviewed by: kib, arichardson MFC after: 2 weeks Relnotes: yes Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D23174 Notes: svn path=/head/; revision=356909
* Deprecate sranddev(3) APIConrad Meyer2019-12-144-26/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=355747
* Regularize my copyright noticeWarner Losh2019-12-041-2/+1
| | | | | | | | | | | | o Remove All Rights Reserved from my notices o imp@FreeBSD.org everywhere o regularize punctiation, eliminate date ranges o Make sure that it's clear that I don't claim All Rights reserved by listing All Rights Reserved on same line as other copyright holders (but not me). Other such holders are also listed last where it's clear. Notes: svn path=/head/; revision=355394
* Revert r354605: Update jemalloc to version 5.2.1.Jason Evans2019-11-111-3/+2
| | | | | | | Compilation fails for non-llvm-based platforms. Notes: svn path=/head/; revision=354606
* Update jemalloc to version 5.2.1.Jason Evans2019-11-111-2/+3
| | | | Notes: svn path=/head/; revision=354605
* bsearch.3: Improve the example.Konstantin Belousov2019-07-171-19/+28
| | | | | | | | | Submitted by: fernape MFC after: 1 week Differential revision: https://reviews.freebsd.org/D19902 Notes: svn path=/head/; revision=350091
* Fix -Wsign-compare warnings in realpath.cAlex Richardson2019-06-261-3/+3
| | | | | | | This is needed in order to build realpath.c as part of rtld. Notes: svn path=/head/; revision=349416
* Add small EXAMPLE section to bsearch.3.Benedict Reuschling2019-05-151-1/+56
| | | | | | | | | | | Submitted by: fernape (via Phabricator) Reviewed by: bcr, jilles, dab Approved by: bcr (man pages), jilles (src) MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D19902 Notes: svn path=/head/; revision=347617
* random.3: Remove obsolete BUGS sectionConrad Meyer2019-04-221-9/+1
| | | | | | | | | | | | | Relative performance to rand(3) is sort of irrelevant; they do different things and a user with sensitivity to RNG performance won't use libc random(3) anyway. The historical note about bad seeding is long obsolete, referring to a 1996 or earlier version of FreeBSD. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=346566
* rand.3: Match better recommendation language from random.3Conrad Meyer2019-04-221-2/+2
| | | | | | | Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=346565
* random.3: Clarify confusing summaryConrad Meyer2019-04-151-2/+2
| | | | | | | | | | | | | | | | | random.3 is only "better" in contrast to rand.3. Both are non-cryptographic pseudo-random number generators. The opening blurbs of each's DESCRIPTION section does emphasize this, and correctly directs unfamiliar developers to arc4random(3). However, the summary (".Nd" or Name description) of random.3 conflicted in tone and message with that warning. Resolve the conflict by clarifying in the Nd section that random(3) is non-cryptographic and pseudo-random. Elide the "better" qualifier which implied a comparison but did not provide a specific object to contrast. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=346251
* Fix order of destructors between main binary and libraries.Konstantin Belousov2019-04-152-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since inits for the main binary are run from rtld (for some time), the rtld_exit atexit(3) handler, which is passed from rtld to the program entry and installed by csu, is installed after any atexit(3) handlers installed by main binary constructors. This means that rtld_exit() is fired before main binary handlers. Typical C++ static constructors are executed from init (either binary or libs) but use atexit(3) to ensure that destructors are called in the right order, independent of the linking order. Also, C++ libraries finalizers call __cxa_finalize(3) to flush library' atexit(3) entries. Since atexit(3) entry is cleared after being run, this would be mostly innocent, except that, atexit(rtld_exit) done after main binary constructors, makes destructors from libraries executed before destructors for main. Fix by reordering atexit(rtld_exit) before inits for main binary, same as it happened when inits were called by csu. Do it using new private libc symbol with pre-defined ABI. Reported. tested, and reviewed by: kan Sponsored by: The FreeBSD Foundation MFC after: 1 week Notes: svn path=/head/; revision=346225
* getopt_long(3): fix case of malformed long optKyle Evans2019-01-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | When presented with an arg string like '-l-', getopt_long will successfully parse out the 'l' short option, then proceed to match '--' against the first longopts entry as it later does a strncmp with len=0. This latter bit is arguably another bug in itself, but presumably not a practical issue as all callers of parse_long_options are already doing the right thing (except this one pointed out). An opt string like '-l-' should be considered malformed and throw a bad argument rather than behaving as if '--' were passed. It cannot possibly do what the invoker expects, and it's probably the result of a typo (ls -l- a) rather than any intent. Reported by: Tony Overfield <toverfield@yahoo.com> Reviewed by: imp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D18616 Notes: svn path=/head/; revision=342757
* Allow multi-byte thousands separators in strfmon(3)Conrad Meyer2018-12-191-14/+23
| | | | | | | | | | PR: 234010 Reported by: Jon Tejnung <jon AT herrskogen.se> Reviewed by: yuripv Differential Revision: https://reviews.freebsd.org/D18605 Notes: svn path=/head/; revision=342260
* Provide set_constraint_handler_s(3) man page.Konstantin Belousov2018-08-192-2/+154
| | | | | | | | | | | | Mention abort_handler_s(3) and ignore_handler_s(3), provide cross-reference from memset(3). Submitted by: Yuri Pankov <yuripv@yuripv.net> MFC after: 3 days Differential revision: https://reviews.freebsd.org/D16797 Notes: svn path=/head/; revision=338051
* Use tab for indent.Konstantin Belousov2018-08-191-1/+1
| | | | | | | | Submitted by: Yuri Pankov <yuripv@yuripv.net> MFC after: 3 days Notes: svn path=/head/; revision=338048
* getopt_long(3): Document behavior of leading characters in optstringKyle Evans2018-08-121-2/+43
| | | | | | | | | | | | | | | | | | Leading '+', '-', and ':' in optstring have special meaning. We briefly mention that the first two have special meaning in that we say POSIXLY_CORRECT turns them off, but we don't actually document their meaning. Add a paragraph to RETURN VALUES explaining how they control the treatment of non-option arguments. A leading ':' has no mention; add a note that it suppresses warnings about missing arguments. Reviewed by: jilles MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D14142 Notes: svn path=/head/; revision=337666
* atoi.3: bump .DdEitan Adler2018-06-131-1/+1
| | | | | | | I touched the man page. Bump Dd by just over 15 years. Notes: svn path=/head/; revision=335044
* libc: remove explicit cast NULL in atoiEitan Adler2018-06-132-3/+3
| | | | | | | | | | There isn't any reason to cast NULL so just remove it. Noticed when cleaning up top. Reviewed by: pstef Notes: svn path=/head/; revision=335041
* libc qsort(3): stop aliasing.Konstantin Belousov2018-06-101-44/+17
| | | | | | | | | | | | | | | | | | | Qsort swap code aliases the sorted array elements to ints and longs in order to do swap by machine words. Unfortunately this breaks with the full code optimization, e.g. LTO. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201 which seems to reference code directly copied from libc/stdlib/qsort.c. PR: 228780 Reported by: mliska@suse.cz Reviewed by: brooks Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D15714 Notes: svn path=/head/; revision=334928
* Bump the date on man pages in r334306Eric van Gyzen2018-05-292-2/+2
| | | | | | | | | | | | | It seems a shame to ruin the patina of the June 4, 1993 date on abort.3, especially since it still matched the date of the SCCS ID, but those are the rules. Reported by: araujo MFC after: 3 days Sponsored by: Dell EMC Notes: svn path=/head/; revision=334308
* Cross-reference abort2(2) from a few man pagesEric van Gyzen2018-05-292-0/+2
| | | | | | | | | | | I didn't know abort2 existed until it was mentioned on a mailing list. Mention it in related pages so others can find it easily. MFC after: 3 days Sponsored by: Dell EMC Notes: svn path=/head/; revision=334306
* Update jemalloc to version 5.1.0.Jason Evans2018-05-111-4/+4
| | | | Notes: svn path=/head/; revision=333477
* Don't put multiple names on a single .Nm line. This fixes apropos(1)Edward Tomasz Napierala2018-04-171-1/+7
| | | | | | | | | | | | | | | | output, from this: strnlen, strlen, strlen,(3) - find length of string │······· ... to this: strlen, strnlen(3) - find length of string PR: 223525 MFC after: 2 weeks Notes: svn path=/head/; revision=332642
* Use standard 2-clause license where copyright is held by the FreeBSD FoundationEd Maste2018-02-021-9/+7
| | | | Notes: svn path=/head/; revision=328785
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-18 01:07:07 +0000