13 Sep
2015
13 Sep
'15
2:32 a.m.
Did any Unix or Unix like OS ever zero fill on
realloc?
On zero fill, I doubt many did that. Many really
early on when memory
was small.
This sparks rminiscence. When I wrote an allocation strategy somewhat
more sophisticated than the original alloc(), I introduced realloc() and
changed the error return from -1 to the honest pointer value 0. The
latter change compelled a new name; "malloc" has been with us ever since.
To keep the per-byte cost of allocation low, malloc stuck with alloc's
nonzeroing policy. The minimal extra code to handle calls that triggered
sbrk had the startling property that five passes through the arena might
be required in some cases--not exactly scalable to giant virtual address
spaces!
It's odd that the later introduction of calloc() as a zeroing malloc()
has never been complemented by a similar variant of realloc().
Am I the only one that remembers realloc() being buggy
on some systems?
I've never met a particular realloc() bug, but realloc does inherit the
portability bug that Posix baked into malloc(). Rob Pike and I
requested that malloc(0) be required to return a pointer distinct from
any live pointer. Posix instead allowed an undefined choice between
that behavior and an error return, confounding it with the out-of-memory
indication. Maybe it's time to right the wrong and retire "malloc".
The name "alloc" might be recycled for it. It could also clear memory
and obsolete calloc().
Doug
13 Sep
13 Sep
3:15 a.m.
New subject: Did realloc ever zero the new memory?
On Sat, Sep 12, 2015 at 08:32:57PM -0400, Doug McIlroy wrote:
It's odd that the later introduction of calloc()
as a zeroing malloc()
has never been complemented by a similar variant of realloc().
That's a really good point. Anyone like these?
void *alloc(size_t bytes);
void *realloc(void *old, size_t want);
void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);
So alloc is new, we can have that. Realloc() is OK? Or not? Does the
current one have weird semantics?
zalloc/zealloc are new, we can have those.
If you guys like these I can push on Linus and the glibc people.
8:09 a.m.
New subject: Did realloc ever zero the new memory?
On Sat, 12 Sep 2015, Larry McVoy wrote:
That's a really good point. Anyone like these?
void *alloc(size_t bytes);
void *realloc(void *old, size_t want);
void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);
So alloc is new, we can have that. Realloc() is OK? Or not? Does the
current one have weird semantics?
zalloc/zealloc are new, we can have those.
If you guys like these I can push on Linus and the glibc people.
I'll vote for those, although my dev days are pretty much over. I've
never liked malloc() etc not clearing memory, although it has been, ahem,
useful, in the past...
And I vaguely recall alloc() from Ed5 days (it was an improvement upon
"sys brk", after all), so it's not new.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
I'll support shark-culling when they have been observed walking on dry land.
14 Sep
14 Sep
5:20 a.m.
New subject: Did realloc ever zero the new memory?
On Sunday, 13 September 2015 at 16:09:55 +1000, Dave Horsfall wrote:
On Sat, 12 Sep 2015, Larry McVoy wrote:
http://xkcd.com/927/
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
That's a really good point. Anyone like
these?
void *alloc(size_t bytes);
void *realloc(void *old, size_t want);
void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);
So alloc is new, we can have that. Realloc() is OK? Or not? Does the
current one have weird semantics?
zalloc/zealloc are new, we can have those.
If you guys like these I can push on Linus and the glibc people.
I'll vote for those, although my dev days are pretty much over. I've
never liked malloc() etc not clearing memory, although it has been, ahem,
useful, in the past... 
17 Sep
17 Sep
6:42 a.m.
New subject: Did realloc ever zero the new memory?
On 9/13/2015 11:20 PM, Greg 'groggy' Lehey wrote:
On Sunday, 13 September 2015 at 16:09:55 +1000, Dave
Horsfall wrote:
Why not crealloc? pronounced 'cereal-oc'? it would behave the same
as
realloc, but explicitly zeroes the area upon allocating it (and maybe
also upon reducing the size of the area, it zeroes the area freed, or
zeroes the area the memory structure was previously located at, if the
whole memory structure has to be moved.)
Borrowing from
http://pubs.opengroup.org/onlinepubs/009695399/functions/realloc.html :
The /crealloc/() function shall change the size of the memory object
pointed to by /ptr/ to the size specified by /size/. The contents of the
object shall remain unchanged up to the lesser of the new and old sizes.
If the new size of the memory object would require movement of the
object, the space for the previous instantiation of the object is
zeroed, then freed. If the new size is larger, the contents of the newly
allocated portion of the object are explicitly set to the value of 0. If
/size/ is 0 and /ptr/ is not a null pointer, the object pointed to is
zeroed, then freed. If the space cannot be allocated, the object shall
remain unchanged.
If /ptr/ is a null pointer, /crealloc/() shall be equivalent to
/calloc/()
<http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html>
for the specified size.
If /ptr/ does not match a pointer returned earlier by /calloc/()
<http://pubs.opengroup.org/onlinepubs/009695399/functions/calloc.html>,
/malloc/()
<http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html>,
/realloc/() or /crealloc/() or if the space has previously been
deallocated by a call to /free/()
<http://pubs.opengroup.org/onlinepubs/009695399/functions/free.html>,
/realloc/() or /crealloc/(), the behavior is undefined.
The order and contiguity of storage allocated by successive calls to
/crealloc/() is unspecified. The pointer returned if the allocation
succeeds shall be suitably aligned so that it may be assigned to a
pointer to any type of object and then used to access such an object in
the space allocated (until the space is explicitly freed or
reallocated). Each such allocation shall yield a pointer to an object
disjoint from any other object. The pointer returned shall point to the
start (lowest byte address) of the allocated space. If the space cannot
be allocated, a null pointer shall be returned.
--
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu(a)gmail.com
jgevaryahu(a)hotmail.com
On Sat, 12 Sep 2015, Larry McVoy wrote:
http://xkcd.com/927/
Greg That's a really good point. Anyone like
these?
void *alloc(size_t bytes);
void *realloc(void *old, size_t want);
void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);
So alloc is new, we can have that. Realloc() is OK? Or not? Does the
current one have weird semantics?
zalloc/zealloc are new, we can have those.
If you guys like these I can push on Linus and the glibc people.
I'll vote
for those, although my dev days are pretty much over. I've
never liked malloc() etc not clearing memory, although it has been, ahem,
useful, in the past... 
13 Sep
13 Sep
9:06 a.m.
New subject: Did realloc ever zero the new memory?
[2015-09-12 18:15] Larry McVoy <lm(a)mcvoy.com>
That's a really good point. Anyone like these?
void *alloc(size_t bytes);
void *realloc(void *old, size_t want);
void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);
Please note, that identifiers are usually remembered by sound
not by letter sequence. `zalloc' and `zealloc' are likely to
be pronounced similar and thus there is a good chance that
this leads to confusion and errors. Furthermore, `calloc' and
`zalloc' are prone to be pronounced equally or understood
equally, especially by non-native speakers.
Choosing good identifiers is a tough task.
meillo
12:32 p.m.
New subject: Did realloc ever zero the new memory?
On Sun, 13 Sep 2015, markus schnalke wrote:
That, of course, depends upon how you pronounce "z". In this part of the
world, it's "zed". No confusion with "see" here down-under...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
I'll support shark-culling when they have been observed walking on dry land.
void
*alloc(size_t bytes);
void *realloc(void *old, size_t want);
void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);
Please note, that identifiers are usually remembered by sound not by
letter sequence. `zalloc' and `zealloc' are likely to be pronounced
similar and thus there is a good chance that this leads to confusion and
errors. Furthermore, `calloc' and `zalloc' are prone to be pronounced
equally or understood equally, especially by non-native speakers.
1:06 p.m.
New subject: Did realloc ever zero the new memory?
[2015-09-13 20:32] Dave Horsfall <dave(a)horsfall.org>
On Sun, 13 Sep 2015, markus schnalke wrote:
That, of course, depends upon how you pronounce "z". In this part of the
world, it's "zed". No confusion with "see" here down-under...
So, if these function will never be available to American English
speaking folks, then I'm all fine with the names. ;-)
meillo
void
*alloc(size_t bytes);
void *realloc(void *old, size_t want);
void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);
Please note, that identifiers are usually remembered by sound not by
letter sequence. `zalloc' and `zealloc' are likely to be pronounced
similar and thus there is a good chance that this leads to confusion and
errors. Furthermore, `calloc' and `zalloc' are prone to be pronounced
equally or understood equally, especially by non-native speakers. 
2:13 p.m.
New subject: Did realloc ever zero the new memory?
On Sun, Sep 13, 2015 at 09:06:48AM +0200, markus schnalke wrote:
Please note, that identifiers are usually remembered
by sound
not by letter sequence. `zalloc' and `zealloc' are likely to
be pronounced similar
While I'd pronounce zealloc as Zee-alloc; I'd not be inclined
to pronounce zalloc that way, nor as Zed-alloc, but as Zal-loc
(rhymes with Sal-loc). Maybe Larry had this pronounciation
in mind?
Similarly, I pronounce 'calloc' as Kal-loc not, See-alloc.
So other folk from England should have no trouble :-)
DF
3:45 p.m.
New subject: Did realloc ever zero the new memory?
Derek Fawcus scripsit:
While I'd pronounce zealloc as Zee-alloc;
I'd not be inclined
to pronounce zalloc that way, nor as Zed-alloc, but as Zal-loc
(rhymes with Sal-loc). Maybe Larry had this pronounciation
in mind?
Similarly, I pronounce 'calloc' as Kal-loc not, See-alloc.
+1
So other folk from England should have no trouble :-)
Nor other Yanks. :-)
That, of course, leads directly to the vexed question of how to pronounce
"char". For me, it is "tcharr", for others "care".
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"
3:30 a.m.
New subject: Did realloc ever zero the new memory?
Doug McIlroy <doug(a)cs.dartmouth.edu> writes:
It's odd that the later introduction of calloc()
as a zeroing malloc()
has never been complemented by a similar variant of realloc().
Speaking of calloc, was it ever envisioned that any implementation would
do anything more sophisticated with the two arguments than multiply them
together (and detect overflow)? Has any such implementation ever
existed? It seems like one of the great mysteries of the C library
design, especially since early implementations didn't do overflow
checking.
The existence of cfree also suggests an intention to eventually have it
use a separate arena from malloc.
4:29 a.m.
New subject: Did realloc ever zero the new memory?
On Sat, Sep 12, 2015 at 6:30 PM, Random832 <random832(a)fastmail.com> wrote:
Doug McIlroy <doug(a)cs.dartmouth.edu> writes:
Alignment perhaps?
-- Charles
It's odd that the later introduction of
calloc() as a zeroing malloc()
has never been complemented by a similar variant of realloc().
Speaking of calloc, was it ever envisioned that any implementation would
do anything more sophisticated with the two arguments than multiply them
together (and detect overflow)? Has any such implementation ever
existed? It seems like one of the great mysteries of the C library
design, especially since early implementations didn't do overflow
checking.
3348
days inactive
3352
days old
11 comments
10 participants
participants (10)
-
Charles Anthony -
Dave Horsfall -
Derek Fawcus -
Doug McIlroy -
Greg 'groggy' Lehey -
John Cowan -
Jonathan Gevaryahu -
Larry McVoy -
markus schnalke -
Random832