A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.5.1 2022-02-26T16:14:42+00:00 2022-02-26T16:14:42+00:00 otto 2022-02-26T16:14:42+00:00 urn:sha1:b9a07308bf393074d3bc822f5d326959d6620f23 in size. This cache is indexed by size (in # of pages), so it is very quick to check. Some programs allocate and deallocate larger allocations in a frantic way. Accomodate those programs by also keeping a cache of regions between 128k and 2M, in a cache of variable sized regions. Tested by many in snaps; ok deraadt@ 2022-02-06T00:29:02+00:00 jsg 2022-02-06T00:29:02+00:00 urn:sha1:330276f39a5e0d5b539d5e8e3e247384f82cbde2 ok jmc@ sthen@ millert@ 2022-01-06T18:58:24+00:00 jmc 2022-01-06T18:58:24+00:00 urn:sha1:bee4e7d6cff50954827dda49f2f9ca3cc0f570b4 from uwe@netbsd -r1.22 ok millert 2021-12-08T22:06:28+00:00 cheloha 2021-12-08T22:06:28+00:00 urn:sha1:8b24559bc32a8fcd130978a513c42659ebf278de lsearch(3) is really just lfind(3) with an additional branch to append the key if lfind(3) fails. If we get rid of the underlying linear_base() function and move the search portion into lfind(3) and the key-copying portion into lsearch(3) we get smaller and simpler code. Misc. notes: - We do not need to keep the historical comment about errno. lsearch(3) is pure computation and does not set errno. That's really all you need to know. The specification reserves no errors, either. - We are using lfind(3) internally now, so it switches from PROTO_DEPRECATED to PROTO_NORMAL in hidden/search.h and needs DEF_WEAK in stdlib/lsearch.c. With advice from guenther@ on symbol housekeeping in libc. Thread: https://marc.info/?l=openbsd-tech&m=163885187632449&w=2 ok millert@ 2021-12-07T04:01:45+00:00 cheloha 2021-12-07T04:01:45+00:00 urn:sha1:cfc78852fcba382d04261ab49ed38b22e811e417 If the key overlaps the end of the array, memcpy(3) mutates the key and copies a corrupted value into the end of the array. If we use memmove(3) instead we at least end up with a clean copy of the key at the end of the array. This is closer to the intended behavior. With input from millert@ and deraadt@. Thread: https://marc.info/?l=openbsd-tech&m=163880307403606&w=2 ok millert@ 2021-12-02T20:58:01+00:00 cheloha 2021-12-02T20:58:01+00:00 urn:sha1:6cb312a90e0db659665950da1acb2da29d74cadf The "lim" variable needs to be a size_t to match nmemb, otherwise we get undefined behavior when nmemb exceeds INT_MAX. Prompted by a blog post by Joshua Bloch: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html Fixed by Chris Torek a long time ago: https://svnweb.freebsd.org/csrg/lib/libc/stdlib/bsearch.c?revision=51742&view=markup ok millert@ 2021-10-24T21:24:20+00:00 deraadt 2021-10-24T21:24:20+00:00 urn:sha1:2cbc009da6303d81a98bd284aae87c1761b472c7 3rd (variadic) mode_t parameter is irrelevant. Many developers in the past have passed mode_t (0, 044, 0644, or such), which might lead future people to copy this broken idiom, and perhaps even believe this parameter has some meaning or implication or application. Delete them all. This comes out of a conversation where tb@ noticed that a strange (but intentional) pledge behaviour is to always knock-out high-bits from mode_t on a number of system calls as a safety factor, and his bewilderment that this appeared to be happening against valid modes (at least visually), but no sorry, they are all irrelevant junk. They could all be 0xdeafbeef. ok millert 2021-10-24T10:05:23+00:00 jsg 2021-10-24T10:05:23+00:00 urn:sha1:6293deec24fd2fc1af41365c46711340cb0d96fb ok mpi@ deraadt@ 2021-10-13T15:04:53+00:00 kn 2021-10-13T15:04:53+00:00 urn:sha1:abee1a1ab2ff268190f5bb2aafb17cccebd49f17 A tiny realpath(3) wrapper to make a porter's life easier. Feedback kettenis deraadt cheloha sthen OK cheloha martijn deraadt 2021-09-19T09:15:22+00:00 tb 2021-09-19T09:15:22+00:00 urn:sha1:f7454b8bede1be416adc77267c65bdcb40ee9f98 This matches the documented behavior more obviously and ensures that these aren't optimized away, although this is unlikely. Discussed with deraadt and otto