3 ms·

I don't get it. The two behaviors are completely orthogonal. Why can't I have a malloc() that does lazy copy-on-write for large arrays and why can't I have an e

I don't get it. The two behaviors are completely orthogonal. Why can't I have a malloc() that does lazy copy-on-write for large arrays and why can't I have an error checking malloc() and why can't I have a calloc() that allocates the memory up front and doesn't zero it out? I get the "it's historic" argument, but this seems like a silly distinction. Sounds like what you want to do practically is basically just make your malloc() wrap a calloc() with size 1, and stop explicitly memset()ing. Or just introduce your own functions: moarmem(n) // malloc(n) moarmemslower(n) // p = malloc(n); memset(p, 0); moarmemfaster(n) // calloc(n, 1) evenmoarmem(p, n); // realloc() fuggetaboutit(p) // free()

kr7 10y ago
> Why can't I have a malloc() that does lazy copy-on-write for large array malloc will generally do lazy copy-on-write above a certain limit; it was 128kb for glibc last time I checked. > why can't I have an error checking malloc() reallocarray is becoming the de-facto standard for that. > why can't I have a calloc() that allocates the memory up front and doesn't zero it out? Er, malloc?
masklinn 10y ago
> Why can't I have a malloc() that does lazy copy-on-write for large arrays reallocarray(3) (though fundamentally that's what malloc does as well, it just doesn't do overflow checking) > why can't I have an error checking malloc() reallocarray(3) (because malloc doesn't get the information, it gets a single size rather than a count and a per-object size) > why can't I have a calloc() that allocates the memory up front and doesn't zero it out? reallocarray(3) > Sounds like what you want to do practically is basically just make your malloc() wrap a calloc() with size 1, and stop explicitly memset()ing. If you're going to memset(0) it there's no reason to use malloc() ever, but it's very common to malloc() then fill the allocation directly, in which case the memsetting is a redundant cost.

kr7 10y ago

> Why can't I have a malloc() that does lazy copy-on-write for large array malloc will generally do lazy copy-on-write above a certain limit; it was 128kb for glibc last time I checked. > why can't I have an error checking malloc() reallocarray is becoming the de-facto standard for that. > why can't I have a calloc() that allocates the memory up front and doesn't zero it out? Er, malloc?

masklinn 10y ago

> Why can't I have a malloc() that does lazy copy-on-write for large arrays reallocarray(3) (though fundamentally that's what malloc does as well, it just doesn't do overflow checking) > why can't I have an error checking malloc() reallocarray(3) (because malloc doesn't get the information, it gets a single size rather than a count and a per-object size) > why can't I have a calloc() that allocates the memory up front and doesn't zero it out? reallocarray(3) > Sounds like what you want to do practically is basically just make your malloc() wrap a calloc() with size 1, and stop explicitly memset()ing. If you're going to memset(0) it there's no reason to use malloc() ever, but it's very common to malloc() then fill the allocation directly, in which case the memsetting is a redundant cost.