What does the "c" in "calloc" mean?
Wolfram Rösler
I compiled a list of acronyms around Unix and the C language,
and found out that I have no idea what the "c" in "calloc"
stands for. Does anyone have an idea?
BTW, the complete list can be found at:
http://www.roesler-ac.de/wolfram/acro/index.htm
If anyone finds that I got some of the acronyms wrong, or
knows of some that should be added to the list, feel free
to let me know.
Thanks for enlightenment
W. Rösler
--
====================================================================
GRP Entwicklungs- und Vertriebsgesellschaft
für Produktionsdatenerfassungsanlagen mbH Wolfram Rösler
Kackertstraße 8 mailto:w...@grp.de
D-52072 Aachen Tel. 0241-88930-17
http://www.grp.de Fax 0241-870787
====================================================================
Mark A. Odell
>Hello.
>
>I compiled a list of acronyms around Unix and the C language,
>and found out that I have no idea what the "c" in "calloc"
>stands for. Does anyone have an idea?
The c is for 'c'leared memory. The calloc() function returns
the block of memory (if sucessful) all set to zero, or, in
other words, cleared.
--
Warmest regards.
Optimize only if it runs too slowly or does not fit, spaces instead of tabs.
Kaz Kylheku
>Hello.
>
>I compiled a list of acronyms around Unix and the C language,
>and found out that I have no idea what the "c" in "calloc"
>stands for. Does anyone have an idea?
It stands for clear, since a new object created by calloc is all zero bytes.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
Andreas Kähäri
Wolfram Rösler <w...@grp.de> wrote:
>Hello.
>
>I compiled a list of acronyms around Unix and the C language,
>and found out that I have no idea what the "c" in "calloc"
>stands for. Does anyone have an idea?
>
Clear, since the space is initialized to all bits zero.
This is, I think, the second time in a short period of time that this
quite unusual question is being asked.
/A
--
Andreas Kähäri,
Uppsala University, Sweden.
-------{ Places to visit: www.gnu.org, www.faqs.org, New Zealand }------
Dan Pop
>In article <8s4pb6$d90$04$1...@news.t-online.com>,
> w...@grp.de wrote:
>>
>> I compiled a list of acronyms around Unix and the C language,
>> and found out that I have no idea what the "c" in "calloc"
>> stands for. Does anyone have an idea?
>
>My wild guess is that it comes from something like "allocate
>with a count of elements".
I tend to agree with this interpretation. If the "c" standed for "clear",
the function's prototype would have been identical to malloc's.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
raw...@my-deja.com
w...@grp.de wrote:
>
> I compiled a list of acronyms around Unix and the C language,
> and found out that I have no idea what the "c" in "calloc"
> stands for. Does anyone have an idea?
My wild guess is that it comes from something like "allocate
with a count of elements".
--
MJSR
Sent via Deja.com http://www.deja.com/
Before you buy.
Mark A. Odell
>>My wild guess is that it comes from something like "allocate
>>with a count of elements".
>
>I tend to agree with this interpretation. If the "c" standed for "clear",
^^^^^^^--- stood
And 'c' does stand for 'c'lear.
Jack Klein
comp.lang.c:
> Hello.
>
> I compiled a list of acronyms around Unix and the C language,
> and found out that I have no idea what the "c" in "calloc"
> stands for. Does anyone have an idea?
>
> BTW, the complete list can be found at:
> http://www.roesler-ac.de/wolfram/acro/index.htm
> If anyone finds that I got some of the acronyms wrong, or
> knows of some that should be added to the list, feel free
> to let me know.
>
> Thanks for enlightenment
> W. Rösler
I'll vote for clear, but I also took a quick look at your site and
wanted to add a comment:
On your ASCII code page, I'd suggest adding a third column to the
table with the numerical value of each control character.
Jack Klein
--
Home: http://jackklein.home.att.net
Dan Pop
>And 'c' does stand for 'c'lear.
How do you know? What's wrong with 'c' for 'c'ounted?
Richard Heathfield
>
> In article <8s4pb6$d90$04$1...@news.t-online.com>,
> Wolfram Rösler <w...@grp.de> wrote:
> >
> >I compiled a list of acronyms around Unix and the C language,
> >and found out that I have no idea what the "c" in "calloc"
> >stands for. Does anyone have an idea?
> >
>
>
> This is, I think, the second time in a short period of time that this
> quite unusual question is being asked.
>
#include "usenet.h"
int msg_Steve_Summit(news comp)
{
return ++comp.lang.c->FAQ;
}
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
Wolfram Rösler
wrote:
>On your ASCII code page, I'd suggest adding a third column to the
>table with the numerical value of each control character.
I'll look into that.
As for the "c" in "calloc", the suggested meanings are "clear"
and "count". Does anybody have any kind of evidence, like
an early source code of calloc (like the explanation for su
in http://www.roesler-ac.de/wolfram/acro/credits.htm#2), or
something like that? If not so, I'll just put both guesses
on the list.
Thanks to all who helped
Dik T. Winter
> On Thu, 12 Oct 2000 16:38:04 GMT, w...@grp.de (Wolfram Rösler) wrote in
> comp.lang.c:
> > http://www.roesler-ac.de/wolfram/acro/index.htm
...
> I'll vote for clear, but I also took a quick look at your site and
> wanted to add a comment:
The consensus on the last discussion was "clear".
>
> On your ASCII code page, I'd suggest adding a third column to the
> table with the numerical value of each control character.
Also, FS = File Separator, SUB = Substitute.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Mark A. Odell
>In <8FCBD7C3Dhj43h...@24.128.8.202>
>verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>
>>And 'c' does stand for 'c'lear.
>
>How do you know? What's wrong with 'c' for 'c'ounted?
Because the only diff. between malloc and calloc is that
it returns the memory bytes in the buffer as "initialized to all bits
CLEARED". There is no mention of counting the bytes.
Andreas Kähäri
Mark A. Odell <verymuchanimpos...@hotmail.com> wrote:
>Dan...@cern.ch (Dan Pop) wrote in <8s63m9$5b0$1...@sunnews.cern.ch>:
>
>>In <8FCBD7C3Dhj43h...@24.128.8.202>
>>verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>>
>>>And 'c' does stand for 'c'lear.
>>
>>How do you know? What's wrong with 'c' for 'c'ounted?
>
>it returns the memory bytes in the buffer as "initialized to all bits
>CLEARED". There is no mention of counting the bytes.
I don't know if that was from the current standard, but the draft C89
says "The space is initialized to all bits zero".
The *big* difference (apart from the zeroing bit) is the signature of
the functions (1 argument vs. 2 arguments). There must be some purpose
for this difference.
scab...@my-deja.com
> >>
> >>>And 'c' does stand for 'c'lear.
> >>
> >>How do you know? What's wrong with 'c' for 'c'ounted?
> >
> >Because the only diff. between malloc and calloc is that
> >it returns the memory bytes in the buffer as "initialized to all bits
> >CLEARED". There is no mention of counting the bytes.
>
> I don't know if that was from the current standard, but the draft C89
> says "The space is initialized to all bits zero".
>
> The *big* difference (apart from the zeroing bit) is the signature of
> the functions (1 argument vs. 2 arguments). There must be some purpose
> for this difference.
Page 252 of K&R 2nd Ed:
"
void *calloc(size_t nobj, size_t size)
calloc returns a pointer to space for an array of nobj objects, each of
size size, ... . The space is initialised to zero bytes.
"
Nuff said? ( Saves us the hassle of doing a multiplication.)
Cheers
Craig
>
> /A
>
> --
> Andreas Kähäri,
> Uppsala University, Sweden.
> -------{ Places to visit: www.gnu.org, www.faqs.org, New Zealand
}------
>
Mark A. Odell
<39e7...@merganser.its.uu.se>:
>>Because the only diff. between malloc and calloc is that
>>it returns the memory bytes in the buffer as "initialized to all bits
>>CLEARED". There is no mention of counting the bytes.
>
>I don't know if that was from the current standard, but the draft C89
>says "The space is initialized to all bits zero".
True but it is an English-ism to equate "clearing" to mean "zeroing".
>The *big* difference (apart from the zeroing bit) is the signature of
>the functions (1 argument vs. 2 arguments). There must be some purpose
>for this difference.
Yes, Since you must specify the number of elements with the size of one of
these elements there is a difference. I'd suspect this allows calloc to more
efficiently clear (or zero) the elements.
I.e. float pFloater = calloc(1000, sizeof *pFloat);
Mark A. Odell
<8FCC69BB8hj43h...@24.128.44.7>:
>these elements there is a difference. I'd suspect this allows calloc to
>more efficiently clear (or zero) the elements.
Good god, I split an infinitive! Sorry let's ignore "to more efficiently
clear (or zero) the elements" and replace it with "to clear (or zero) the
elements more efficiently". Man I hate when I do that.
Andreas Kähäri
><39e7...@merganser.its.uu.se>:
>
>>>Because the only diff. between malloc and calloc is that
>>>it returns the memory bytes in the buffer as "initialized to all bits
>>>CLEARED". There is no mention of counting the bytes.
>>
>>I don't know if that was from the current standard, but the draft C89
>>says "The space is initialized to all bits zero".
>
>True but it is an English-ism to equate "clearing" to mean "zeroing".
>
I take "to clear something" to mean "to assign some
implementation-defined value to something" (didn't find anything about
this in the standard although it talks about clearing indicators and
flags).
>>The *big* difference (apart from the zeroing bit) is the signature of
>>the functions (1 argument vs. 2 arguments). There must be some purpose
>>for this difference.
>
>Yes, Since you must specify the number of elements with the size of one of
>these elements there is a difference. I'd suspect this allows calloc to more
>efficiently clear (or zero) the elements.
Hmmm... even though the standard doesn't specify *how* the allocated
memory should be cleared/initialized? Does the standard make these
kinds of considerations for other functions?
>
>I.e. float pFloater = calloc(1000, sizeof *pFloat);
(float *pFloat = calloc(1000, sizeof *pFloat);)
"Clear" was my first thought too, but after the posts from Dan Pop I'm
not so sure. Does really matter?
Andreas Kähäri
>
>
>> >>
>> >>>And 'c' does stand for 'c'lear.
>> >>
>> >>How do you know? What's wrong with 'c' for 'c'ounted?
>> >
>> >it returns the memory bytes in the buffer as "initialized to all bits
>> >CLEARED". There is no mention of counting the bytes.
>>
>> I don't know if that was from the current standard, but the draft C89
>> says "The space is initialized to all bits zero".
>>
>> the functions (1 argument vs. 2 arguments). There must be some purpose
>> for this difference.
>
>Nuff said? ( Saves us the hassle of doing a multiplication.)
Although it's a very good book, K&R2 does not constitute the C
standard anymore.
Mark A. Odell
<39e7...@merganser.its.uu.se>:
>>True but it is an English-ism to equate "clearing" to mean "zeroing".
>I take "to clear something" to mean "to assign some
>implementation-defined value to something" (didn't find anything about
>this in the standard although it talks about clearing indicators and
>flags).
You take it wrong, sorry. To set a flip flop is to set its output to one, to
clear it is to set it to zero. This set/clear notation is often carried over
into software.
>"Clear" was my first thought too,
Stick with your gut feeling then.
>but after the posts from Dan Pop I'm
>not so sure. Does really matter?
I think the group has beaten Dan into submission on this, in a friendly way
of course.
Andreas Kähäri
raw...@my-deja.com
verymuchanimpos...@hotmail.com (Mark A. Odell) wrote:
> Dan...@cern.ch (Dan Pop) wrote in <8s63m9$5b0$1...@sunnews.cern.ch>:
>
> >In <8FCBD7C3Dhj43h...@24.128.8.202>
> >verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
> >
> >>And 'c' does stand for 'c'lear.
> >
> >How do you know? What's wrong with 'c' for 'c'ounted?
>
> it returns the memory bytes in the buffer as "initialized to all bits
> CLEARED". There is no mention of counting the bytes.
I'm currently convinced that my conjecture was not correct (not
the original reason for the c), but I find it more mnemonic:
you can't count on clearing chars to clear the complete collection
of C types, but you cannot correctly call calloc without a count.
--
MJSR
Morris Dovey
> and...@emailme.net.REMOVE (Andreas Kähäri) wrote in
> <39e7...@merganser.its.uu.se>:
>
> >[snip] Does really matter?
>
> I think the group has beaten Dan into submission on this, in a friendly way
> of course.
It probably only really matters to ("How many angels can dance on the head of a
pin") philosophers and very geekish historians.
On the matter of beating Dan into submission (on anything): I don't think I'd
care to risk any of /my/ money on a bet...
Morris Dovey
West Des Moines, Iowa USA
mrd...@iedu.com
Larry Weiss
> I'm currently convinced that my conjecture was not correct (not
> the original reason for the c), but I find it more mnemonic:
> you can't count on clearing chars to clear the complete collection
> of C types, but you cannot correctly call calloc without a count.
>
But that count can always be exactly 1 if you want it to be.
You are given an opportunity to avoid computing the exact
total amount of space by instead giving two numbers that when
multiplied will give that total, but you don't really have
to take advantage of the convenience.
The memory returned from calloc is not obligated only to holding
n objects each with a certain size that matches exactly the
value of arguments given to calloc.
- Larry Weiss
Dan Pop
>Dan...@cern.ch (Dan Pop) wrote in <8s63m9$5b0$1...@sunnews.cern.ch>:
>
>>In <8FCBD7C3Dhj43h...@24.128.8.202>
>>verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>>
>>>And 'c' does stand for 'c'lear.
>>
>>How do you know? What's wrong with 'c' for 'c'ounted?
>
>Because the only diff. between malloc and calloc is that
>it returns the memory bytes in the buffer as "initialized to all bits
>CLEARED".
Is this the *only* difference? One learns new things every day :-)
When did they replace the old calloc prototype with the new:
void *calloc(size_t size);
???
>There is no mention of counting the bytes.
Indeed, it's not the bytes that are counted, but the array elements!
If we look carefully at the prototypes of the two functions:
void *malloc(size_t size);
void *calloc(size_t num_of_elts, size_t elt_size);
we can easily figure out why we have two functions and what the original
intention behind each one was:
malloc is obviously intended for allocating buffers, whose initialisation
doesn't matter because they'll be overwritten anyway.
calloc is obviously intended for allocating arrays of objects, its first
parameter being the 'c'ount of elements in the array. Whoever invented
this function decided that it would be a good idea to also initialise the
allocated array, before giving it to the programmer. The only meaningful
initialisation for an array of objects of unknown type and structure is
to set all the bits to zero. On *most* platforms, this will guarantee
that *all* the scalar types are nullified, including floating point types
and pointers.
If the main idea behind calloc was to be a malloc returning a cleared
block of memory, it is virtually impossible to explain its different
interface.
It makes more sense to assume that the name of the function reflects its
intended purpose (allocate enough memory for a certain element count)
rather than a specification detail of secondary importance.
But, of course, only the programmer who invented it knows for sure :-)
raw...@my-deja.com
<0885083D00D394A2.CC6A586B...@lp.airnews.net>,
Larry Weiss <l...@airmail.net> wrote:
> raw...@my-deja.com wrote:
> > I'm currently convinced that my conjecture was not correct (not
> > the original reason for the c), but I find it more mnemonic:
> > you can't count on clearing chars to clear the complete collection
> > of C types, but you cannot correctly call calloc without a count.
> >
>
> But that count can always be exactly 1 if you want it to be.
But you still have to supply it. By contrast, you can ignore the
byte clearing and pretend that the allocated memory has indeterminate
values, and probably should if you intend to use any of it as a
non-char type. I do use the count, and pretty much ignore the
clearing because it doesn't work for all types.
Mark A. Odell
<39e7...@merganser.its.uu.se>:
>I think I stay undecided on this whole matter.
You must comply, we are the Borg, resistance is futile. The 'c' stands for
'c'lear.
Clark S. Cox, III
> Dan...@cern.ch (Dan Pop) wrote in <8s5gfm$rcv$1...@sunnews.cern.ch>:
>
> >>My wild guess is that it comes from something like "allocate
> >>with a count of elements".
> >
> >I tend to agree with this interpretation. If the "c" standed for "clear",
> ^^^^^^^--- stood
Gee, thank you, Mr English language police. Not everyone grew up
speaking English. I really find it offensive when people feel the need
to correct others in this manner..
Dan Pop
>I think the group has beaten Dan into submission on this, in a friendly way
>of course.
No way! :-) Getting me beaten into submission is not an issue of
quantity, but of quality. You have to come with arguments better than
mine to achieve this. The number of people agreeing with your inferior
argumentation is irrelevant :-)
Dan Pop
>The memory returned from calloc is not obligated only to holding
>n objects each with a certain size that matches exactly the
>value of arguments given to calloc.
What matters here is that it is guaranteed to be large enough to
hold those objects, if the calloc call succeeds.
Dan Pop
>Mark A. Odell <verymuchanimpos...@hotmail.com> wrote:
>
>> Dan...@cern.ch (Dan Pop) wrote in <8s5gfm$rcv$1...@sunnews.cern.ch>:
>>
>> >>My wild guess is that it comes from something like "allocate
>> >>with a count of elements".
>> >
>> >I tend to agree with this interpretation. If the "c" standed for "clear",
>> ^^^^^^^--- stood
>
> Gee, thank you, Mr English language police. Not everyone grew up
>speaking English. I really find it offensive when people feel the need
>to correct others in this manner..
I'm grateful to Mark for the correction. It's the best way to prevent me
from repeating that silly mistake.
Larry Weiss
> Larry Weiss <l...@airmail.net> writes:
> >The memory returned from calloc is not obligated only to holding
> >n objects each with a certain size that matches exactly the
> >value of arguments given to calloc.
>
> What matters here is that it is guaranteed to be large enough to
> hold those objects, if the calloc call succeeds.
>
Does it matter (apart from style) if you use
calloc(1,100*sizeof(int))
- or-
calloc(100,sizeof(int))
for the call to get sufficient storage for 100 int's ?
- Larry Weiss
Kaz Kylheku
>Dan Pop wrote:
>> Larry Weiss <l...@airmail.net> writes:
>> >The memory returned from calloc is not obligated only to holding
>> >n objects each with a certain size that matches exactly the
>> >value of arguments given to calloc.
>>
>> What matters here is that it is guaranteed to be large enough to
>> hold those objects, if the calloc call succeeds.
>>
>
>Does it matter (apart from style) if you use
>
> calloc(1,100*sizeof(int))
> - or-
> calloc(100,sizeof(int))
In this case it doesn't matter but it could make a difference if the number of
ints N was so large that the multiplication N*sizeof(int) wraps. It's possible
that calloc(N, sizeof(int)) will do the multiplication in a way that does not
wrap and actually give you an object that big.
Larry Weiss
So it is possible in some implementations that calloc() can
allocate larger blocks of memory that malloc() ?
Maybe the 'c' is for "colossal". 8-)
Or do I just need to write the expression involving the multiplication
more carefully?
- Larry Weiss
Dan Pop
>Dan Pop wrote:
>> Larry Weiss <l...@airmail.net> writes:
>> >The memory returned from calloc is not obligated only to holding
>> >n objects each with a certain size that matches exactly the
>> >value of arguments given to calloc.
>>
>> What matters here is that it is guaranteed to be large enough to
>> hold those objects, if the calloc call succeeds.
>>
>
>Does it matter (apart from style) if you use
>
> calloc(1,100*sizeof(int))
> - or-
> calloc(100,sizeof(int))
>
>for the call to get sufficient storage for 100 int's ?
No, but the whole calloc bussines is nothing more than mere stylistic
sugar. Its functionality can be achieved with a multiplication, a malloc
and a memset call.
Dan Pop
>So it is possible in some implementations that calloc() can
>allocate larger blocks of memory that malloc() ?
Everything is possible, including a malloc that can allocate larger
blocks than calloc. People are seeing too much in calloc's interface.
>Or do I just need to write the expression involving the multiplication
>more carefully?
If you are the calloc implementor you don't have to worry about it.
If the result doesn't fit in a size_t, the caller has invoked undefined
behaviour, so you can happily allocate the wrapped around result of the
multiplication, without bothering to check anything :-)
Dan Pop
>In this case it doesn't matter but it could make a difference if the number of
>ints N was so large that the multiplication N*sizeof(int) wraps. It's possible
>that calloc(N, sizeof(int)) will do the multiplication in a way that does not
>wrap and actually give you an object that big.
Possible, but highly unlikely. Remember that size_t is large enough to
represent the size of *any* supported object. If the multiplication's
result doesn't fit in a size_t, you have already invoked undefined
behaviour (obviously not because of the unsigned integer "overflow" per
se).
Mark A. Odell
<1eig0mk.osa2bu1tiqpogN%clar...@yahoo.com>:
>> >I tend to agree with this interpretation. If the "c" standed for
>> >"clear",
>> ^^^^^^^--- stood
>
> Gee, thank you, Mr English language police. Not everyone grew up
>speaking English. I really find it offensive when people feel the need
>to correct others in this manner..
It was not intended to be mean, maybe I should use little :-). Just thought
you might like to know how we English people use the language. If you do not
care to improve your English, my apologies.
Mark A. Odell
>> Gee, thank you, Mr English language police. Not everyone grew up
>>speaking English. I really find it offensive when people feel the need
>>to correct others in this manner..
>
>I'm grateful to Mark for the correction. It's the best way to prevent me
>from repeating that silly mistake.
I didn't mean to be mean about it. Just thought it might save you from
repeating it again. Sorry for any offense inflicted.
Mark A. Odell
> Gee, thank you, Mr English language police. Not everyone grew up
>speaking English. I really find it offensive when people feel the need
>to correct others in this manner..
I posted a reply to you thinking you made the English error but you didn't.
Lighten up.
Dan Pop
>Dan...@cern.ch (Dan Pop) wrote in <8s7jj7$scl$1...@sunnews.cern.ch>:
>
>>I'm grateful to Mark for the correction. It's the best way to prevent me
>>from repeating that silly mistake.
>
>I didn't mean to be mean about it. Just thought it might save you from
>repeating it again. Sorry for any offense inflicted.
If I was offended by anything, it was by my own carelessness. Most of
my English mistakes are due to ignorance, but it was not the case here.
Robert Stankowic
>
> In <1eig0mk.osa2bu1tiqpogN%clar...@yahoo.com> clar...@yahoo.com (Clark S. Cox, III) writes:
>
> >Mark A. Odell <verymuchanimpos...@hotmail.com> wrote:
> >
> >> Dan...@cern.ch (Dan Pop) wrote in <8s5gfm$rcv$1...@sunnews.cern.ch>:
> >>
> >> >>My wild guess is that it comes from something like "allocate
> >> >>with a count of elements".
> >> >
> >> ^^^^^^^--- stood
> >
> >speaking English. I really find it offensive when people feel the need
> >to correct others in this manner..
>
> from repeating that silly mistake.
>
> --
> Dan Pop
> CERN, IT Division
> Email: Dan...@cern.ch
> Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
So do I. Avoiding such mistakes helps me to express my questions and
answers here more precise(ly?) and I think, often a precise question
already has the answer in it
Robert
Brian Evan Blank
>
> Hello.
>
> I compiled a list of acronyms around Unix and the C language,
BTW, clc is not in the Miscellaneous section!
> and found out that I have no idea what the "c" in "calloc"
> stands for. Does anyone have an idea?
A c.l.c. whodunit: a mystery, scant clues, and a few plausible
suspects.
Let me preface all my comments with the admission that I do
not possess a copy of K&R1 and have never seen one. If I had,
then I would be able to answer some of my questions. It might
even stop my theory dead in its tracks. I hesitate to advance
a conjecture based on secondary sources, but this is a pretty
good forum for finding correction where needed. In any event
the entire thread has been conjectural.
MJSR> My wild guess is that it comes from something like
MJSR> "allocate with a count of elements".
Dan Pop> I tend to agree with this interpretation. If the "c"
Dan Pop> standed for "clear", the function's prototype would have
Dan Pop> been identical to malloc's.
First, I am reassured by the two opinions about "count" above.
When you teach C you will inevitably be asked about the
significance of the "c" in calloc. I have never been convinced
by the usual explanation of "clear." I had put that down to
my being a mathematician who does not think of "clear" and
"initialize" in the same way. So it is nice to see that some
programmers don't go along with the "clear" theory, even if
MJSR is not convinced by his own conjecture.
There is really no clue that I can see in K&R2: no "clear",
no "contiguous", no "count", and, may I add, no "character."
I do not recall any indication - in the discussion of calloc
or elsewhere - that the authors think of "initialization to 0"
as "clearing".
There is some indirect evidence to support "count." I have
some C books from the early 1980s and it was common then to
use "count" and "size", respectively, in the parameter list
of calloc.
I am not sure about Dan's inference concerning prototypes. The
inference would be logical if malloc and calloc came from the
same source. I am not sure that the two functions did. The
earliest C books that I have mention calloc but not malloc.
(Indeed, one book that does not mention malloc says "You probably
have a function in your library called calloc()." Note the
"probably"!) I have another book from the mid 1980s that says
that "some C implementations have a function called malloc but
in the Kernighan-Ritchie 'standard' there is just one allocation
function, calloc." So, really old-timers, is it true that malloc
started off as an extension? (A December 1986 description of
the draft ANSI standard does list malloc. The first parameter
of calloc was by then not written "count" but "nmemb", as it
continues to be.)
Mark A. Odell> it is an English-ism to equate "clearing" to
Mark A. Odell> mean "zeroing".
As I indicated, I thought that it was a programmer-ism. I
certainly don't equate the two.
<OT>
Mark A. Odell> Good god, I split an infinitive!
Good god, this is Usenet!
Mathematicians often divide people into three types: those who
can count and those who can't. H.W. Fowler divided the
English-speaking world into five types of persons according
to their various relationships with split-infinitives. He then
expended about 1800 words on the subject. In doing so he warned
that "those upon whom the fear of infinitive-splitting sits heavy
should remember that to give conclusive evidence, by distortions,
of misconceiving the nature of the split-infinitive is far more
damaging to their literary pretensions than an actual lapse would
be; for it exhibits them as deaf to the normal rhythm of English
sentences." Naturally you would expect Yankee authority to express
this thought more directly. From the Columbia Dictionary for
Writers: "[Banning the split infinitive] has no foundation in
grammar, logic, rhetoric, or common sense. Go ahead and split if
you want to. Never to split is to seriously stifle." And, in case
you harbor reservations about splitting the parts of a compound
verb, I quote from the same source: "Those who would ban splitting
a compound verb are even more antediluvian than the
antisplitinfinitive troglodytes."
That said, in the case in question, it was better to not split
the infinitive. :-)
</OT>
Andreas Kähäri> [concerning "to clear something"] didn't find
Andreas Kähäri> anything about this in the standard although
Andreas Kähäri> it talks about clearing indicators and flags.
Andreas Kähäri> Although it's a very good book, K&R2 does not
Andreas Kähäri> constitute the C standard anymore.
Since this is a historical question, K&R (especially K&R1) would
have far more to say about the likely reason for the "c" in
calloc than the Standard possibly could. If you look through
K&R2, then you will find many references to "initialize to 0"
and "initialize with zero" but you will not find one "clear
to 0."
Mark A. Odell> I think the group has beaten Dan into submission
Mark A. Odell> on this.
As he retorted, it didn't and there is no reason to think that
it should have. Although "c" could stand for "clear", no evidence
has been presented to support that conjecture. OTOH, there is
enough circumstantial evidence to cast doubt upon it. Moreover,
if calloc predated malloc, then there would be no need to
emphasize the "clear" to distinguish calloc from the utility of
a not-yet-extant library function. I agree with Dan that "count"
is more plausible than "clear" (but I think that there is an
equally plausible possibility).
Morris Dovey> It probably only really matters to philosophers
Morris Dovey> and very geekish historians.
Only! A visit to a.f.c. will reveal how many very geekish
historians there are! (And let us not stop to subdivide
each of the already very large number of classes of readers of
this thread: eg., those who (1) can't count, (2) neither know
nor care about split-infinitives, and (3) are very geekish
historians.)
Dan Pop> If the main idea behind calloc was to be a malloc
Dan Pop> returning a cleared block of memory, it is virtually
Dan Pop> impossible to explain its different interface.
Well, if different programmers wrote calloc and malloc then that
would be enough to explain the difference. All the early sources
that I have indicate that malloc followed calloc. So it does not
appear that the intention was for calloc to be a malloc with
initialization. It does seem likely that malloc was intended to
be a calloc without (often unnecessary) overhead. Furthermore,
in the case of general data types, initialization to 0 would not
only be unnecessary, it would be useless. I suspect that the
return types of calloc and malloc once constituted an important
distinction that was removed by the ANSI committee. There was
also a deprecated, later vanished, allocation function that
returned a pointer to long. Can anyone confirm that malloc was
born as a void* returning function? This is a missing link for a
theory I am about to float, particularly if a void*-returning
malloc coexisted with the original incarnation of calloc.
For the sake of argument, let me suggest "character allocation" as
a possibility. If you ask for the distance between two points, then
a numerical answer is not meaningful unless you have specified the
units of measurement. If you ask for memory then you need to specify
the units of measurement. In C, "c"haracter is the basic unit of
measurement for data. It would be natural to ask for "c"haracter
"alloc"ation in C and according to its return type, that is exactly
what calloc did in the beginning. Admittedly, the goal of calloc was
always more general than character allocation. For one thing, it
would be pointless to pass two arguments just for character
allocation. Nevertheless, before ANSI, calloc(count,size) returned a
char*. You could, of course, use it for other data types but doing so
then _required_ a cast. (As is well-known, the practice of casting a
pointer returned by calloc was so established that K&R2 continued to
state "it must be cast into the appropriate type" even after ANSI
removed that need.) Whereas calloc originally "alloc"ated memory
and returned a pointer to "c"har, I propose (with no degree of
conviction) that calloc is the abbreviation of "c"har "alloc"ate.
And before the howls of protest start arriving, I remind you that
the OP asked only for "an idea." He did not insist upon a good
idea. In any event, if I have liberated just one man from
split-infinitive anxiety, then this article will have been
worthwhile.
(To reach me, replace my middle name with my first.)
--
Brian Blank You cannot program
Department of Mathematics a crooked machine
Washington University in St. Louis to go straight.
St. Louis, MO 63130 -Edsger Dijkstra
raw...@my-deja.com
ev...@math.wustl.edu wrote:
> Wolfram Rösler wrote:
> > and found out that I have no idea what the "c" in "calloc"
> > stands for. Does anyone have an idea?
>
> A c.l.c. whodunit: a mystery, scant clues, and a few plausible
> suspects.
> MJSR> My wild guess is that it comes from something like
> MJSR> "allocate with a count of elements".
>
> Dan Pop> I tend to agree with this interpretation. If the "c"
> Dan Pop> standed for "clear", the function's prototype would have
> Dan Pop> been identical to malloc's.
>
> First, I am reassured by the two opinions about "count" above.
> When you teach C you will inevitably be asked about the
> significance of the "c" in calloc. I have never been convinced
> by the usual explanation of "clear." I had put that down to
> my being a mathematician who does not think of "clear" and
> "initialize" in the same way. So it is nice to see that some
> programmers don't go along with the "clear" theory, even if
> MJSR is not convinced by his own conjecture.
Unfortunately, I am a mathematician; I am least certain of
my conjecture precisely because it was almost certainly a
programmer who invented calloc. Dan Pop's agreement was a
surprise, and it undermines the certainty of my uncertainty.
Whatever the original meaning, I prefer "count" as a mnemonic,
though.
> There is really no clue that I can see in K&R2: no "clear",
> no "contiguous", no "count", and, may I add, no "character."
If this really was the sole original allocation function,
perhaps the "c" is just for C (the language).
> I do not recall any indication - in the discussion of calloc
> or elsewhere - that the authors think of "initialization to 0"
> as "clearing".
But it is a common programmer-ism, especially since flags are
typically cleared by setting them to zero. And it has been
inflicted on non-programmers, in the form of calculators on
which the "clear" button results in zero. (Except for those
calculators where "clear" results in an empty stack, which
have inflicted other programmer-isms on the general public.)
> There is some indirect evidence to support "count." I have
> some C books from the early 1980s and it was common then to
> use "count" and "size", respectively, in the parameter list
> of calloc.
Harbison and Steele (2nd edition) used elt_count, which in part
prompted my original conjecture. It also lists both malloc and
calloc, with char * returns and unsigned int arguments, but notes
that (Draft Proposed) ANSI C uses void * and size_t.
> For the sake of argument, let me suggest "character allocation" as
> a possibility. If you ask for the distance between two points, then
> a numerical answer is not meaningful unless you have specified the
> units of measurement. If you ask for memory then you need to specify
> the units of measurement. In C, "c"haracter is the basic unit of
> measurement for data. It would be natural to ask for "c"haracter
> "alloc"ation in C and according to its return type, that is exactly
> what calloc did in the beginning. Admittedly, the goal of calloc was
> always more general than character allocation. For one thing, it
> would be pointless to pass two arguments just for character
> allocation. Nevertheless, before ANSI, calloc(count,size) returned a
> char*. You could, of course, use it for other data types but doing so
> then _required_ a cast.
But in the early language, typing was so weak that there was no
need of a cast; casts were a fairly late addition.
> (As is well-known, the practice of casting a
> pointer returned by calloc was so established that K&R2 continued to
> state "it must be cast into the appropriate type" even after ANSI
> removed that need.) Whereas calloc originally "alloc"ated memory
> and returned a pointer to "c"har, I propose (with no degree of
> conviction) that calloc is the abbreviation of "c"har "alloc"ate.
But char * was the only sensible return type for generic allocation
before void * existed, and malloc certainly existed before void
became a keyword. Since char * was used for a generic pointer
type, it seems unlikely that calloc would emphasize the char part
of things, especially if there were no other allocation functions.
But good evidence for this conjecture would be to find some
indication of early allocation functions such as ialloc (returning
int *), dalloc (returning double *) or palloc (returning perhaps
char **) which appropriately initialized elements to 0, 0.0 or
NULL. But the existence of these would probably hinge on
recognizing that setting bytes to zero would not portably set
other types to zero, and I would expect that this was a later
development than dynamic allocation functions.
If only one allocation function originally existed, why wouldn't
it have just been called alloc? Or was there a primordial alloc
function? If so, what did it do?
Martin Peach
Dan Pop <Dan...@cern.ch> wrote in message
news:8s63m9$5b0$1...@sunnews.cern.ch...
> In <8FCBD7C3Dhj43h...@24.128.8.202>
>
> How do you know? What's wrong with 'c' for 'c'ounted?
/\/\/\/*= Martin
Mark A. Odell
@weber.videotron.net>:
> >And 'c' does stand for 'c'lear.
>>
>> How do you know? What's wrong with 'c' for 'c'ounted?
>Or 'c' for 'chunk' as in allocate a chunk of memory...
How about 'c' for 'c'omply, as in, "You must comply, resistance is futile"?
DarkCode
[...large snip...]
> If only one allocation function originally existed, why wouldn't
> it have just been called alloc? Or was there a primordial alloc
> function? If so, what did it do?
What about calloc was orginaly writen by an American programmer, who
used calloc as a shortening for a mysteriously mispelled word? ;-)
The use of calloc rather then just alloc does suggest to me as well
that there might of been other functions with simalor names (maybe
even by the same designer(s)) or that other memory functions already
existed.
I tend to thing of calloc as a "count and clear allocation", since
it both allocates a counted number of objects of a given size, and
clears the allocated memory. So I just overload the meaning of the
'c' as both "count" and "clear" (and maybe "complex" as a way to
remember that calloc may be slower then malloc).
> --
> MJSR
--
struct DarkCode;
// "Note that this code is untested and I'm rather tired, so
// there's probably a bug." -- Ben Pfaff
Al Aab
a department head of a toronto high school
teaching data processing
confessed, in front of his class,
that he did not know the meaning of
EOF
calloc =? CORE alloc
Mark A. Odell (verymuchanimpos...@hotmail.com) wrote:
: mar...@vr-labs.com (Martin Peach) wrote in <M21H5.4322$5W2.161603
: @weber.videotron.net>:
: --
: Warmest regards.
--
=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
al aab, ex seders moderator sed u soon
it is not zat we do not see the s o l u t i o n
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Chris Mears
> in the sixties
> a department head of a toronto high school
> teaching data processing
>
> confessed, in front of his class,
> that he did not know the meaning of
> EOF
The meaning of "EOF" would depend on the context.
> calloc =? CORE alloc
What's a core?
Andreas Kähäri
>af...@torfree.net (Al Aab) wrote:
>
>> in the sixties
>> a department head of a toronto high school
>> teaching data processing
>>
>> confessed, in front of his class,
>> that he did not know the meaning of
>> EOF
>
>
>> calloc =? CORE alloc
>
>What's a core?
>
The same "core" as in "segmentation violation, core dumped".
<URL:http://www.tuxedo.org/~esr/jargon/html/entry/core.html>.
Sounds reasonable... too.
/A
--
Andreas Kähäri,
Uppsala University, Sweden.
----------------------------------------------------------------
Debian GNU/Linux, the choice of a GNU generation
raw...@my-deja.com
af...@torfree.net (Al Aab) wrote:
> in the sixties
> a department head of a toronto high school
> teaching data processing
>
> confessed, in front of his class,
> that he did not know the meaning of
> EOF
Ralph Silverman returns.
> calloc =? CORE alloc
Perhaps the c should be taken to stand for confusion, conundrum,
or confounding.
Dan Pop
>af...@torfree.net (Al Aab) wrote:
>
>> calloc =? CORE alloc
>
>What's a core?
Something that Unix loves to dump when the programmer can't control his
pointers :-)
Daniel Haude
Dan Pop <Dan...@cern.ch> wrote
in Msg. <8s5gfm$rcv$1...@sunnews.cern.ch>
| In <8s4s17$ovi$1...@nnrp1.deja.com> raw...@my-deja.com writes:
|
| >In article <8s4pb6$d90$04$1...@news.t-online.com>,
| > w...@grp.de wrote:
| >
| >My wild guess is that it comes from something like "allocate
| >with a count of elements".
|
| the function's prototype would have been identical to malloc's.
I think the 'c' stands for 'commit' because the memory is immediately put
to use. Committed.
--Daniel
--
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." -- Bill Gates, "The Road Ahead"
Andreas Kähäri
Daniel Haude wrote:
>On 12 Oct 2000 23:11:50 GMT,
> Dan Pop <Dan...@cern.ch> wrote
> in Msg. <8s5gfm$rcv$1...@sunnews.cern.ch>
>| In <8s4s17$ovi$1...@nnrp1.deja.com> raw...@my-deja.com writes:
>|
>| >In article <8s4pb6$d90$04$1...@news.t-online.com>,
>| > w...@grp.de wrote:
>| >
>| >My wild guess is that it comes from something like "allocate
>| >with a count of elements".
>|
>| I tend to agree with this interpretation. If the "c" standed for "clear",
>| the function's prototype would have been identical to malloc's.
>
>I think the 'c' stands for 'commit' because the memory is immediately put
>to use. Committed.
<joke>
No, no. It's "changed" because the data is changed from being
uninitialised to being initialised...
...or maybe it's "crayon" because most of us initially used crayons to
write zeros.
</joke>
/A
--
Andreas Kähäri, Uppsala University, Sweden
------------------------------------------------------------------------
"If you leave now, you're going to miss the real experience."
-- Richard M. Stallman, Stockholm 1986. Visit www.gnu.org
Larry Weiss
> I think the 'c' stands for 'commit' because the memory is immediately put
> to use. Committed.
>
I recall using an AIX box where there was an actual delay of
allocation between a malloc() and first actual use of the memory.
So on that platform (which was invented way after the name calloc()
was invented BTW) "c" for committed would be a nice reminder
of that difference.
I also remember that either c.l.c or c.std.c (or maybe both)
discussed whether such a delaying technique was conforming.
I don't remember the concensus decision.
- Larry Weiss
Dan Pop
>Daniel Haude wrote:
>> I think the 'c' stands for 'commit' because the memory is immediately put
>> to use. Committed.
>
>I recall using an AIX box where there was an actual delay of
>allocation between a malloc() and first actual use of the memory.
>So on that platform (which was invented way after the name calloc()
>was invented BTW) "c" for committed would be a nice reminder
>of that difference.
Not really. If the memory block was freshly obtained from the OS, calloc
wouldn't have to touch it, because it was guaranteed to be all zeroes.
So, calloc is not any safer than malloc on such a system.
>I also remember that either c.l.c or c.std.c (or maybe both)
>discussed whether such a delaying technique was conforming.
>I don't remember the concensus decision.
This is because there wasn't any consensus :-)
Both Digital Unix and AIX provide mechanisms for getting a reliable
malloc. Linux doesn't (AFAIK), but it is more careful when honouring
a malloc request: it will succeed only if there is enough virtual memory
available at the time when malloc was called. So, the cautious Linux
programmer could follow any successful [cm]alloc call by a memset call,
to make sure that the memory will be there when he needs it.
Wolfram Rösler
I put a summary of the results of the discussion about the
meaning of the "c" in calloc on my acronym page. You find it
at: http://www.roesler-ac.de/wolfram/acro/all.htm#calloc
Thanks to all who joined in the discussion.
--
====================================================================
GRP Entwicklungs- und Vertriebsgesellschaft
für Produktionsdatenerfassungsanlagen mbH Wolfram Rösler
Kackertstraße 8 mailto:w...@grp.de
D-52072 Aachen Tel. 0241-88930-17
http://www.grp.de Fax 0241-870787
====================================================================
Jens Schweikhardt
# In <5DA29C6D67FFD7DB.31C8A5DE...@lp.airnews.net> Larry Weiss <l...@airmail.net> writes:
#>Daniel Haude wrote:
#>> I think the 'c' stands for 'commit' because the memory is immediately put
#>> to use. Committed.
#>
#>I recall using an AIX box where there was an actual delay of
#>allocation between a malloc() and first actual use of the memory.
#>So on that platform (which was invented way after the name calloc()
#>was invented BTW) "c" for committed would be a nice reminder
#>of that difference.
# Not really. If the memory block was freshly obtained from the OS, calloc
# wouldn't have to touch it, because it was guaranteed to be all zeroes.
# So, calloc is not any safer than malloc on such a system.
#>I also remember that either c.l.c or c.std.c (or maybe both)
#>discussed whether such a delaying technique was conforming.
#>I don't remember the concensus decision.
# This is because there wasn't any consensus :-)
Too bad C99 didn't clarify. The discussions have been coming up
time and again on comp.std.c. I predict they continue to do so :-)
# Both Digital Unix and AIX provide mechanisms for getting a reliable
# malloc. Linux doesn't (AFAIK), but it is more careful when honouring
# a malloc request: it will succeed only if there is enough virtual memory
# available at the time when malloc was called. So, the cautious Linux
# programmer could follow any successful [cm]alloc call by a memset call,
# to make sure that the memory will be there when he needs it.
If anyone is interested in what his/her OS does with malloc/calloc,
i.e. if it is honest or cheats on you and rams a knife in your back,
you might want to try one of the 1996 IOCCC winning programs, AFAIR
it's the one that ends in 3.c. See http://www.ioccc.org/years.html#1996
for details and whatever you do, don't try it on a production machine!
(BTW, it's a POSIX C source, not ISO C).
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Mpeglitis Nikos
"Jens Schweikhardt" <schw...@diamant.noc.dfn.de> wrote in message
news:8tc4lv$pq1$1...@regensburg.shuttle.de...
> Dan Pop <Dan...@cern.ch> wrote:
> # In <5DA29C6D67FFD7DB.31C8A5DE...@lp.airnews.net>
Larry Weiss <l...@airmail.net> writes:
>
> #>Daniel Haude wrote:
> #>> I think the 'c' stands for 'commit' because the memory is immediately
put
> #>> to use. Committed.
What about this one:
'c' stands for 'continuous'
Bye,
--
-=\*| Nick Mpeglitis |*/=-
E-mail address: coy...@edu.physics.uoc.gr
nmpe...@ucnet.uoc.gr
Personal Web Page: http://www.edu.physics.uoc.gr/~coyote
Dan Pop
>What about this one:
>
>'c' stands for 'continuous'
Is there any C function for allocating discontinuous memory blocks?
Barry Schwarz
"let's see how much of Usenet we can consume with a useless thread
that goes on for months completely devoid of content and even get the
lurkers to jump in on". Understand that this is only a rough
translation from the original sanskrit where it originally applied to
political speeches.
<<Remove the del for email>>
Daniel Haude
Wolfram Rösler <w...@grp.de> wrote
in Msg. <8s6bfs$uhj$01$1...@news.t-online.com>
| As for the "c" in "calloc", the suggested meanings are "clear"
| and "count".
And "commit". I haven't made it up; I'm sure I've read it in some source
that I took as authoritative, like a book or some C library documentation
(probably Borland C).