openbsd/src/lib, branch OPENBSD_3_6_BASE A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_3_6_BASE 2004-09-07T13:47:08+00:00 This commit was manufactured by cvs2git to create tag 'OPENBSD_3_6_BASE'. 2004-09-07T13:47:08+00:00 cvs2svn admin@example.com 2004-09-07T13:47:08+00:00 urn:sha1:86583d7d10a19466b6f2bf9f08e4c59ef07f4150 mips is now 64 bits so use a 64 bit config 2004-09-07T13:47:07+00:00 pefo 2004-09-07T13:47:07+00:00 urn:sha1:25b7af03e5890e88d0ac4e079de8ca2057ff93d3 mention strtonum(3) 2004-08-22T21:47:41+00:00 jaredy 2004-08-22T21:47:41+00:00 urn:sha1:633fc554b41a52a44458a5f8967f01dc3ea386de ok millert jmc pedro mips->mips64 2004-08-11T17:38:15+00:00 pefo 2004-08-11T17:38:15+00:00 urn:sha1:257f9fa1c8da62d7aacb0a6747c804e359d1e6ad Back out to brk(2) version. 2004-08-11T06:22:45+00:00 tdeval 2004-08-11T06:22:45+00:00 urn:sha1:65193da08860e45add39313084d63c8d45f79a37 The mmap(2) code is cool and it has already uncovered some bugs in other code. But some issues remain on some archs, and we can't afford that for production. Don't worry, it will be back soon... I'll make sure of it... cleanup mips 2004-08-06T22:41:41+00:00 pefo 2004-08-06T22:41:41+00:00 urn:sha1:6f880eb7fcdbe1fa895d8a32b59128966f46aab2 - Remove the userland data limit check. It's mmap(2)'s job. 2004-08-05T21:55:21+00:00 tdeval 2004-08-05T21:55:21+00:00 urn:sha1:3c4566ef1079a75ca935096218c75f551d8e26c7 - When malloc_abort==0 (MALLOC_OPTIONS=a), don't abort in wrterror(). fine deraadt@ Missing check for NULL. 2004-08-04T19:12:53+00:00 tdeval 2004-08-04T19:12:53+00:00 urn:sha1:c83fda0075d86da98f69b2e750005da6bf478117 It's not really possible to make strtonum() deal with unsigned long 2004-08-03T19:38:01+00:00 millert 2004-08-03T19:38:01+00:00 urn:sha1:ea13120433234de14cfef017f9b900c5d4e3874e long values properly so don't bother trying. This greatly simplifies the code. tedu@ OK with input from otto@ and others. After a long gestation period, here comes our custom version of malloc(3) 2004-08-01T08:45:39+00:00 tdeval 2004-08-01T08:45:39+00:00 urn:sha1:14931f8ab7a337e1d1f0d6ff78c8d42ffeaf0189 using mmap(2) instead of sbrk(2). To make a long story short, using mmap(2) in malloc(3) allows us to draw all the benefits from our mmap(2)'s randomization feature, closing the effort we did for returning memory blocks from random addresses. Tested for a long time by many, thanks to them. Go for it ! deraadt@