Page MenuHomeFreeBSD

memory(3): Mention more functions.
ClosedPublic

Authored by des on Oct 13 2023, 2:47 PM.
Tags
None
Referenced Files
Unknown Object (File)
Apr 30 2024, 9:14 AM
Unknown Object (File)
Apr 30 2024, 9:14 AM
Unknown Object (File)
Apr 30 2024, 9:14 AM
Unknown Object (File)
Apr 30 2024, 9:14 AM
Unknown Object (File)
Apr 30 2024, 9:14 AM
Unknown Object (File)
Apr 30 2024, 6:06 AM
Unknown Object (File)
Feb 11 2024, 3:20 PM
Unknown Object (File)
Feb 3 2024, 9:53 AM
Subscribers

Details

Reviewers
None
Group Reviewers
manpages
Commits
rGa66d27e22fa0: memory(3): Mention more functions.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

des requested review of this revision.Oct 13 2023, 2:47 PM
des retitled this revision from memory(3): mention reallocf(). to memory(3): Mention more functions..Oct 13 2023, 3:13 PM
emaste added inline comments.
lib/libc/stdlib/memory.3
41–45

we should maybe drop "general" now?

posix_memalign(3) should be added.

In some sense obsoleted sbrk(2) could be mentioned as well.

Listing mmap as same kind of memory management function as e.g. malloc is strange.

In D42191#962622, @kib wrote:

Listing mmap as same kind of memory management function as e.g. malloc is strange.

I agree but it's been there for 30 years. I just added munmap(2) because if we're listing free(3) then it's weird to leave out munmap(2).

des marked an inline comment as done.Oct 13 2023, 3:27 PM

I missed that some of these are just sorted properly now, not added. I suggested to DES on IRC that we should caution against alloca, based on my mistaken impression that mentioning it here is new.

It is probably mentioning sbrk as well, including a note about both sbrk and alloca that they shouldn't be used.

I missed that some of these are just sorted properly now, not added. I suggested to DES on IRC that we should caution against alloca, based on my mistaken impression that mentioning it here is new.

The alloca(3) man page already warns against using it.

It is probably mentioning sbrk as well, including a note about both sbrk and alloca that they shouldn't be used.

I disagree, sbrk(2) is not really memory management, just a foundation on which you can build your own memory management.

Difference between mmap/munmap and everything else in the list would be that third-party malloc implementations that can be dyn-loaded, interpose all listed functions, but not mmap/munmap.

In D42191#962637, @des wrote:

It is probably mentioning sbrk as well, including a note about both sbrk and alloca that they shouldn't be used.

I disagree, sbrk(2) is not really memory management, just a foundation on which you can build your own memory management.

So is mmap(). In FreeBSD, sbrk(2) is really a made-up mmap(2).

In D42191#962645, @kib wrote:
In D42191#962637, @des wrote:

It is probably mentioning sbrk as well, including a note about both sbrk and alloca that they shouldn't be used.

I disagree, sbrk(2) is not really memory management, just a foundation on which you can build your own memory management.

So is mmap(). In FreeBSD, sbrk(2) is really a made-up mmap(2).

No, you can use mmap() / munmap() directly to allocate and free blocks of memory. You can't use sbrk(2) in that manner.

This revision was not accepted when it landed; it landed in state Needs Review.Oct 18 2023, 2:09 PM
This revision was automatically updated to reflect the committed changes.