This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
DJ Delorie wrote:
Perhaps a good compromise would be to retain current behavior for 32-bit targets (where allocations bigger than 2Gb are realistic) but limit them to PTRDIFF_MAX on 64 bit targets, (where a 5 exabyte allocation is not reasonable).
I'm not sure I see the point of doing it that way. A 2**63 allocation already fails now. The main practical problem here is 2**31 allocations, which can cause applications to fail later in mysterious ways on 32-bit hosts. We've by and large insulated GNU core utilities against this problem, but it was a bit of a pain (and the job is not completely done) and it'd be better if glibc did it for us.
Perhaps a memory-allocation option of some sort? The default should be a PTRDIFF_MAX limit, but applications needing larger allocations could set the option first.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |