Author: brooks Date: Thu May 24 18:32:54 2018 New Revision: 334176 URL: https://svnweb.freebsd.org/changeset/base/334176
Log: Indicate the brk/sbrk are deprecated and not portable. More firmly suggest mmap(2) instead. Include the history of arm64 and riscv shipping without brk/sbrk. Mention that sbrk(0) produces unreliable results. Reviewed by: emaste, Marcin Cieślak MFC after: 3 days Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D15535 Modified: head/lib/libc/sys/brk.2 Modified: head/lib/libc/sys/brk.2 ============================================================================== --- head/lib/libc/sys/brk.2 Thu May 24 18:22:13 2018 (r334175) +++ head/lib/libc/sys/brk.2 Thu May 24 18:32:54 2018 (r334176) @@ -28,7 +28,7 @@ .\" @(#)brk.2 8.4 (Berkeley) 5/1/95 .\" $FreeBSD$ .\" -.Dd December 15, 2015 +.Dd May 24, 2018 .Dt BRK 2 .Os .Sh NAME @@ -51,6 +51,10 @@ and .Fn sbrk functions are legacy interfaces from before the advent of modern virtual memory management. +They are deprecated and not present on the arm64 or riscv architectures. +The +.Xr mmap 2 +interface should be used to allocate pages instead. .Ef .Pp The @@ -152,6 +156,11 @@ The .Fn brk function appeared in .At v7 . +.Fx 11.0 +introduced the arm64 and riscv architectures which do not support +.Fn brk +or +.Fn sbrk . .Sh BUGS Mixing .Fn brk @@ -168,3 +177,9 @@ It is not possible to distinguish this from a failure caused by exceeding the maximum size of the data segment without consulting .Xr getrlimit 2 . +.Pp +.Fn sbrk +is sometimes used to monitor heap use by calling with an argument of 0. +The result is unlikely to reflect actual utilization in combination with an +.Xr mmap 2 +based malloc. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
