memory(3): Mention more functions.

[des]

even more

[emaste]

lib/libc/stdlib/memory.3

41–45

we should maybe drop "general" now?

[kib]

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.

[des]

no generals

[des]

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]

add posix_memalign

[emaste]

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.

[des]

In D42191#962633, @emaste wrote:

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.

[kib]

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.

[kib]

In D42191#962637, @des wrote:

In D42191#962633, @emaste 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).

[des]

In D42191#962645, @kib wrote:

In D42191#962637, @des wrote:

In D42191#962633, @emaste 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.