aboutsummaryrefslogtreecommitdiff
path: root/lib/libc/stdlib
Commit message (Collapse)AuthorAgeFilesLines
...
* strfmon: Trim the SPACE from international currency symbolJose Luis Duran2022-10-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | The international currency symbol (int_curr_symbol) has a mandatory SPACE character as the last character. Trim this space after reading it, otherwise this extra space will always be printed when displaying the int_curr_symbol. Fixes the output when the international currency format is selected (%i). Locale Format Before After en_US.UTF-8 [%i] [USD 123.45] [USD123.45] fr_FR.UTF-8 [%i] [123,45 EUR ] [123,45 EUR] Note that the en_US.UTF-8 locale states that no space should be printed between the currency symbol and the value (sep_by_space = 0). Reviewed by: kib PR: 267282 Github PR: #619 MFC after: 1 week
* strfmon: Avoid an out-of-bounds accessJose Luis Duran2022-10-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid an out-of-bounds access when trying to set the space_char using an international currency format (%i) and the C/POSIX locale. The current code tries to read the SPACE from int_curr_symbol[3]: currency_symbol = strdup(lc->int_curr_symbol); space_char = *(currency_symbol+3); But on C/POSIX locales, int_curr_symbol is empty. Three implementations have been examined: NetBSD[1], Darwin[2], and Illumos[3]. Only NetBSD has fixed it[4]. Darwin and NetBSD also trim the mandatory final SPACE character after reading it. Locale Format Darwin/NetBSD FreeBSD/Illumos en_US.UTF-8 [%i] [USD123.45] [USD 123.45] fr_FR.UTF-8 [%i] [123,45 EUR] [123,45 EUR ] This commit only fixes the out-of-bounds access. [1]: https://github.com/NetBSD/src/blob/trunk/lib/libc/stdlib/strfmon.c [2]: https://opensource.apple.com/source/Libc/Libc-1439.141.1/stdlib/NetBSD/strfmon.c.auto.html [3]: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/locale/strfmon.c [4]: https://github.com/NetBSD/src/commit/3d7b5d498aa9609f2bc9ece9c734c5f493a8e239 Reviewed by: kib PR: 267282 Github PR: #619 MFC after: 1 week
* strfmon: Fix typos in source code commentsJose Luis Duran2022-10-251-2/+2
| | | | | | | | | | s/defult/default s/internaltion/international Reviewed by: kib PR: 267282 Github PR: #619 MFC after: 1 week
* strfmon: Fix typo in constantJose Luis Duran2022-10-251-4/+4
| | | | | | | | | s/SUPRESS_CURR_SYMBOL/SUPPRESS_CURR_SYMBOL Reviewed by: kib PR: 267282 Github PR: #619 MFC after: 1 week
* strfmon: Code cleanupJose Luis Duran2022-10-251-64/+68
| | | | | | | | | | No functional change intended. Not claiming full style(9) compliance. Reviewed by: kib PR: 267282 Github PR: #619 MFC after: 1 week
* Alter the prototype of qsort_r(3) to match POSIX, which adopted theEd Schouten2022-09-306-19/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | glibc-based interface. Unfortunately, the glibc maintainers, despite knowing the existence of the FreeBSD qsort_r(3) interface in 2004 and refused to add the same interface to glibc based on grounds of the lack of standardization and portability concerns, has decided it was a good idea to introduce their own qsort_r(3) interface in 2007 as a GNU extension with a slightly different and incompatible interface. With the adoption of their interface as POSIX standard, let's switch to the same prototype, there is no need to remain incompatible. C++ and C applications written for the historical FreeBSD interface get source level compatibility when building in C++ mode, or when building with a C compiler with C11 generics support, provided that the caller passes a fifth parameter of qsort_r() that exactly matches the historical FreeBSD comparator function pointer type and does not redefine the historical qsort_r(3) prototype in their source code. Symbol versioning is used to keep old binaries working. MFC: never Relnotes: yes Reviewed by: cem, imp, hps, pauamma Differential revision: https://reviews.freebsd.org/D17083
* libc: drop "All rights reserved" from Foundation copyrightsEd Maste2022-08-0411-11/+11
| | | | | | | | | This has already been done for most files that have the Foundation as the only listed copyright holder. Do it now for files that list multiple copyright holders, but have the Foundation copyright in its own section. Sponsored by: The FreeBSD Foundation
* libc: ANSIfy div / ldiv function definitionsEd Maste2022-07-282-4/+2
| | | | | MFC after: 1 week Sponsored by: The FreeBSD Foundation
* Remove "All Rights Reserved" from FreeBSD Foundation libc copyrightsEd Maste2022-07-212-2/+0
| | | | | | | As per the updated FreeBSD copyright template. These were unambiguous cases where the Foundation was the only listed copyright holder. Sponsored by: The FreeBSD Foundation
* libc: Add HISTORY sections to the manual pagesGordon Bergling2022-05-052-2/+13
| | | | | | | | | | There are some sections which could be improved and work to do so is on going. The work will be covered via 'X-MFC-WITH' commits. Obtained from: OpenBSD MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D34759
* getenv(3): Fix two typos in source code commentsGordon Bergling2022-04-091-2/+2
| | | | | | - s/peform/perform/ MFC after: 3 days
* qsort.c: prevent undefined behaviorStefan Eßer2022-01-131-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. MFC after: 1 week
* libc: add clearenv functionMariusz Zaborski2021-11-074-3/+49
| | | | | | | | | | The clearenv(3) function allows us to clear all environment variable in one shot. This may be useful for security programs that want to control the environment or what variables are passed to new spawned programs. Reviewed by: scf, markj (secteam), 0mp (manpages) Differential Revision: https://reviews.freebsd.org/D28223
* Fix null pointer subtraction in mergesort()Dimitry Andric2021-08-271-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. MFC after: 3 days
* _Exit(3): document implementationKonstantin Belousov2021-08-081-6/+14
| | | | | | | | | | | | | | Remove a useless note about unlinking temporary files, they are unlinked in tmpfile(3) [1]. Add a note about __cxa_atexit(). Explain exactly what are the FreeBSD implementation differences between exit() and _Exit(). Noted by: markj [1] Reviewed by: emaste, markj Sponsored by: The FreeBSD Foundation MFC after: 3 days Differential revision: https://reviews.freebsd.org/D31425
* libc qsort(3): Eliminate ambiguous sign comparisonConrad Meyer2021-07-292-1/+8
| | | | | | | | | | | | | | | | The left side of the MIN() expression is the (signed) result of pointer subtraction (ptrdiff_t). The right hand side is the also the (signed) result of pointer subtraction, additionally subtracting the element size ('es'), which is unsigned size_t. This coerces the right-hand expression into an unsigned value. MIN(signed, unsigned) triggers -Wsign-compare. Sorting elements of size greater than SSIZE_MAX is nonsensical, so we can instead treat the element size as ssize_t, leaving the right-hand result the same signedness as the left. Reviewed by: arichardson, kib Differential Revision: https://reviews.freebsd.org/D31292
* Fix race between first rand(3) calls with _once().Alexander Motin2021-07-211-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
* Revert "Fix race between first rand(3) calls."Alexander Motin2021-07-211-7/+2
| | | | | | | | It is going to be reimplemented with _once(). This reverts commit 28d70deaafa62c5d1602de5272c0aad0fcca8aff. MFC after: 1 month
* Fix race between first rand(3) calls.Alexander Motin2021-07-201-2/+7
| | | | | | | | | | 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
* libc/qsort: Don't allow interposing recursive callsAlex Richardson2021-02-181-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
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-03 18:00:57 +0000