On Tue, Jul 09, 2019 at 10:24:53AM -0700, Graham Percival wrote: > On Tue, Jul 09, 2019 at 07:17:39AM +0200, Martin Husemann wrote: > > The classical "data segment" (limited by RLIMIT_DATA) is not used much > > nowadays in NetBSD. Especially malloc() does not use it. > > > > RLIMIT_DATA The maximum size (in bytes) of the data segment for a > > process; this defines how far a program may extend its > > break with the sbrk(2) system call. > > > > > > In ancient times malloc allocated memory via sbrk(2), but nowadays it uses > > mmap(2) with anonymous memory. > > I have no complaint about the internal implementation of malloc(). But POSIX > says that: > > RLIMIT_DATA > This is the maximum size of a data segment of the process, in bytes. If
I think you don't grasp what Martin's telling you. POSIX does not precisely define "data segment of the process"; nor does it state that there cannot be more than one. Our implementation doesn't really have such; so, though it might be desirable to ensure a process cannot allocate more than RLIMIT_DATA bytes, it is not a violation that it cannot, so long as said allocations don't come from a single "data segment of the process" (which in our implementation they do not). The concept of a process having a single "data segment" managed with sbrk() is very old and is not really relevant to modern Unix implementations. If POSIX wants to redefine RLIMIT_DATA in some way more useful in the modern era, this might be good; but as it stands, the problem is that the limit is enforced, but it does not, perhaps, limit what many users initially think it ought to. Thor
