slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) (12/30/88)
It seems to me that most programmers, in giving examples here, use malloc()
instead of calloc(). It seems to me that, with the headache I always get
thinking of C strings, calloc would be a more common procedure. Would someone
please enlighten me why is malloc so much more popular?
----
Wishing you Joyful Holidays and a Happy New Year!
Stan Olejniczak Internet: slores%gables.span@umigw.miami.edu
University of Miami UUCP: {uunet!gould}!umbio!solejni
Miami, Florida, USA Voice: (305)-547-6005
My opinions cannot possibly represent the views of anyone else!peter@ficc.uu.net (Peter da Silva) (01/01/89)
In article <gables.416@umigw.miami.edu>, slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: > It seems to me that most programmers, in giving examples here, use malloc() > instead of calloc(). It seems to me that, with the headache I always get > thinking of C strings, calloc would be a more common procedure. Would someone > please enlighten me why is malloc so much more popular? Kind of a waste to clear out the memory when you're just about to overwrite it anyway. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
eric@snark.UUCP (Eric S. Raymond) (01/02/89)
In article <gables.416@umigw.miami.edu>, Stanislaw L. Olejniczak writes: > It seems to me that most programmers, in giving examples here, use malloc() > instead of calloc(). It seems to me that, with the headache I always get > thinking of C strings, calloc would be a more common procedure. Would someone > please enlighten me why is malloc so much more popular? The calloc(3) code is just a shell around malloc(3), one that hides a single multiplication and zero-fills the allocated area. I use calloc(3) more myself because I often rely on the zero-fill property, but I often refer to such uses as mallocs because that's what's *really* going on inside the shell. I think other programmers often do likewise; perhaps this is what is confusing you. -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/02/89)
In article <gables.416@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: >It seems to me that most programmers, in giving examples here, use malloc() >instead of calloc(). It seems to me that, with the headache I always get >thinking of C strings, calloc would be a more common procedure. Would someone >please enlighten me why is malloc so much more popular? I don't understand the relevance to C strings.. Most often, once an object is allocated, it is filled with meaningful contents. Seldom is what calloc() would have provided the appropriate contents for the object, so using calloc() would waste CPU time to no advantage. calloc() is only useful when you definitely want 0-valued chars (NOT other data types) for the initial contents of a newly allocated object. (In non-portable applications, one can sometimes use calloc() to obtain 0 values for other structure member types, depending on the internal representation used by the architecture, but why get in the habit of using non-portable kludges when the task is easily enough done portably?)
wald-david@CS.YALE.EDU (david wald) (01/04/89)
In article <9254@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <gables.416@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: >>It seems to me that most programmers, in giving examples here, use malloc() >>instead of calloc(). It seems to me that, with the headache I always get >>thinking of C strings, calloc would be a more common procedure. Would someone >>please enlighten me why is malloc so much more popular? > >I don't understand the relevance to C strings.. > >Most often, once an object is allocated, it is filled with meaningful >contents. Seldom is what calloc() would have provided the appropriate >contents for the object, so using calloc() would waste CPU time to no >advantage. calloc() is only useful when you definitely want 0-valued >chars (NOT other data types) for the initial contents of a newly >allocated object. (In non-portable applications, one can sometimes >use calloc() to obtain 0 values for other structure member types, >depending on the internal representation used by the architecture, >but why get in the habit of using non-portable kludges when the task >is easily enough done portably?) There is one possibility of a situation where calloc could be more useful than malloc, however. In some virtual memory systems it is possible to allocate memory filled with a zero bit pattern without actually paging through the memory range. In theory, there are applications where this would save time. I don't know how many implementations actually do this, or how useful it is in those that do. ============================================================================ David Wald wald-david@yale.UUCP waldave@yalevm.bitnet wald-david@cs.yale.edu "A monk, a clone and a ferengi decide to go bowling together..." ============================================================================
dave@onfcanim.UUCP (Dave Martindale) (01/05/89)
I haven't used calloc for years. I malloc a chunk of memory, then explicitly initialize the things that need to be initialized. This allows the reader to see exactly what the default values are, and which fields need to be provided with values. It also avoids a nasty portability bug: I've seen people who use calloc to zero their allocated arrays or structures assume that "all bits zero" is the proper value for floating-point zero - definitely not true on all machines. An explicit initialization to 0.0 is always correct.
ashcraft@yale.UUCP (Cleve Ashcraft) (01/05/89)
In article <eaCKX#4UXCPK=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >In article <gables.416@umigw.miami.edu>, Stanislaw L. Olejniczak writes: >> It seems to me that most programmers, in giving examples here, use malloc() >> instead of calloc(). It seems to me that, with the headache I always get >> thinking of C strings, calloc would be a more common procedure. Would someone >> please enlighten me why is malloc so much more popular? > >The calloc(3) code is just a shell around malloc(3), one that hides a single >multiplication and zero-fills the allocated area. I use calloc(3) more myself >because I often rely on the zero-fill property, but I often refer to such uses >as mallocs because that's what's *really* going on inside the shell. I think >other programmers often do likewise; perhaps this is what is confusing you. "zero-fills the area" how? for ints? floats? doubles? i've got in the habit of malloc'ing everything and then zeroing (appropriatly) the data if needed. lack of trust, i guess. --cleve ashcraft ashcraft@cs.yale.edu
darin@nova.laic.uucp (Darin Johnson) (01/06/89)
Actually, calloc() is not always a shell around malloc()! On an early Pyramid, I had spent lots of wasted time tracking down a bug, that fixed itself when I used free() for malloc()ed objects, and cfree() for calloc()ed objects. In the buggy version, free() was used for everything... Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) "You can't fight in here! This is the war room.."
pcb@usl.usl.edu (Peter C. Bahrs) (01/06/89)
In article <9254@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <gables.416@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: > >It seems to me that most programmers, in giving examples here, use malloc() > >please enlighten me why is malloc so much more popular? > > I don't understand the relevance to C strings.. > > Most often, once an object is allocated, it is filled with meaningful > contents. Seldom is what calloc() would have provided the appropriate > contents for the object, so using calloc() would waste CPU time to no What if you dynamically allocate strings and use malloc?... there may or may not be a \0 in string[0]...I doubt it? Therefore an initial call to if (strcmp(string,"")) may or may not return true! calloc, although more time consuming (not very much) insures empty or zero filled memory.
nevin1@ihlpb.ATT.COM (Liber) (01/06/89)
In article <46857@yale-celray.yale.UUCP> wald-david@CS.YALE.EDU (david wald) writes: |There is one possibility of a situation where calloc could be more |useful than malloc, however. In some virtual memory systems it is |possible to allocate memory filled with a zero bit pattern without |actually paging through the memory range. In this case, wouldn't malloc() just call the same routine as calloc()? Since calloc() always has to do more work than malloc(), malloc() should always get the best performance. -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (312) 979-4751 IH 4F-410 ' ) ) "I will not be pushed, filed, stamped, indexed, / / _ , __o ____ briefed, debriefed or numbered! My life is my own!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
nevin1@ihlpb.ATT.COM (Liber) (01/06/89)
In article <46929@yale-celray.yale.UUCP> ashcraft@yale-celray.UUCP (Cleve Ashcraft) writes: |"zero-fills the area" how? for ints? floats? doubles? It sets all the bits to 0. |i've got in the habit of malloc'ing everything and then zeroing |(appropriatly) the data if needed. This usually leads to a more portable program, which is generally a good thing. -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (312) 979-4751 IH 4F-410 ' ) ) "I will not be pushed, filed, stamped, indexed, / / _ , __o ____ briefed, debriefed or numbered! My life is my own!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
andrew@alice.UUCP (Andrew Hume) (01/06/89)
one (admittedly weak) reason for using calloc is that it insulates you from 16-bit int compilers on 32-bit pointer machines. calloc(1024, 1024) gives you 1MB with 16 or 32 bit ints whereas malloc(1024*1024) may give you none.
wald-david@CS.YALE.EDU (david wald) (01/06/89)
In article <9339@ihlpb.ATT.COM> nevin1@ihlpb.UUCP (55528-Liber,N.J.) writes: >In article <46857@yale-celray.yale.UUCP> wald-david@CS.YALE.EDU (david wald) writes: >| >|There is one possibility of a situation where calloc could be more >|useful than malloc, however. In some virtual memory systems it is >|possible to allocate memory filled with a zero bit pattern without >|actually paging through the memory range. > >In this case, wouldn't malloc() just call the same routine as calloc()? >Since calloc() always has to do more work than malloc(), malloc() should >always get the best performance. It might be that malloc() would skip whatever step performed the "fill", where the fill operation actually consists of setting some tag indicating the default value for all bytes in the page. calloc() would still be slightly less efficient than malloc(), but much, much more efficient than zeroing the memory "by hand." Besides, if portability is an issue, you can't depend on malloc() doing that zeroing operation, even if it's the same as calloc() in whatever implementation you're using. As I said in my original posting, I don't know of any actual implementations that do this, although I'm told there are some where it's possible. Does anyone have any hard data on this? ============================================================================ David Wald wald-david@yale.UUCP waldave@yalevm.bitnet wald-david@cs.yale.edu "A monk, a clone and a ferengi decide to go bowling together..." ============================================================================
scs@adam.pika.mit.edu (Steve Summit) (01/06/89)
In article <gables.416@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: >It seems to me that most programmers, in giving examples here, use malloc() >instead of calloc(). Would someone >please enlighten me why is malloc so much more popular? calloc is essentially worthless. The zero-fill operation it provides is rarely useful in portable programs, for reasons which have already correctly been mentioned. I advocate replacing any contemplated call to calloc(n, s) with malloc(n * s) followed by explicit initialization and/or zero fill, if required. I wish calloc had never been standardized; its incremental utility is quite low. (ANSI probably had no choice, though, since existing code must be protected.) There are claims that calloc can be "more efficient" (there's that word again) under contorted circumstances on virtual memory machines with demand- zero pages, but we went through all that on comp.std.c a month or two ago, and it doesn't bear repeating here. Steve Summit scs@adam.pika.mit.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/07/89)
In article <403@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes:
-Actually, calloc() is not always a shell around malloc()! On an early
-Pyramid, I had spent lots of wasted time tracking down a bug, that fixed
-itself when I used free() for malloc()ed objects, and cfree() for
-calloc()ed objects. In the buggy version, free() was used for
-everything...
The bug was in the Pyramid implementation of calloc()/cfree().
calloc()ed storage may legitimately be freed with free().leo@philmds.UUCP (Leo de Wit) (01/07/89)
In article <620@usl.usl.edu> pcb@usl.usl.edu (Peter C. Bahrs) writes: |In article <9254@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: |> Most often, once an object is allocated, it is filled with meaningful |> contents. Seldom is what calloc() would have provided the appropriate |> contents for the object, so using calloc() would waste CPU time to no | |What if you dynamically allocate strings and use malloc?... there may or may |not be a \0 in string[0]...I doubt it? Therefore an initial call to |if (strcmp(string,"")) may or may not return true! Why should you want to use the value of a variable that was never assigned to? This is the same mistake as something like: void foo() { int i; if (i == 0) { printf("The auto variable was zero\n"); } else { printf("The auto variable was %d\n",i); } } $ lint foo.c foo.c: foo.c(5): warning: i may be used before set <== foo defined( foo.c(2) ), but never used printf returns value which is always ignored |calloc, although more time consuming (not very much) insures empty or zero |filled memory. Fact is that the zero-filled area is often worthless, as many others pointed out: objects are not assigned null values (at least not portably), and why prefilling with zero bits an object that you are going to assign a new value to anyway. If you're talking about relative speeds malloc / calloc, you could be very surprised; calloc could be an order of magnitude slower, if malloc for instance does something like taking a block from a free block list (maintaining free block lists with block sizes equal to a power of 2). Well, it depends ... Leo.
bagpiper@oxy.edu (Michael Paul Hunter) (01/09/89)
In article <620@usl.usl.edu> pcb@usl.usl.edu (Peter C. Bahrs) writes: >In article <9254@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: >> In article <gables.416@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: >> >It seems to me that most programmers, in giving examples here, use malloc() >> >please enlighten me why is malloc so much more popular? >> stuff.... >What if you dynamically allocate strings and use malloc?... there may or may >not be a \0 in string[0]...I doubt it? Therefore an initial call to >if (strcmp(string,"")) may or may not return true! > >calloc, although more time consuming (not very much) insures empty or zero >filled memory. ouch!!! Anybody who uses calloc for the side effect that they can then consider that piece of memory to be a null terminated string is asking for a headache in the future. What happens when the next person inherits your code and has to speed it up? That person changes the callocs to mallocs and causes a bug (a naive one, but a bug). What about if that person pulls the *alloc out of the inner loop....your calloc only helps on the first iteration... I think it would be better (and faster) to malloc and set the first element of the array to (char)NULL if you want it to be a 0 length string....make it a SLM if you are really emphatic. Mike
jimp@cognos.uucp (Jim Patterson) (01/10/89)
In article <9339@ihlpb.ATT.COM> nevin1@ihlpb.UUCP (55528-Liber,N.J.) writes: >In article <46857@yale-celray.yale.UUCP> wald-david@CS.YALE.EDU (david wald) writes: > >| In some virtual memory systems it is >|possible to allocate memory filled with a zero bit pattern without >|actually paging through the memory range. > >In this case, wouldn't malloc() just call the same routine as calloc()? It may, initially, but it also will recycle memory returned by a free() call. malloc() is under no obligation to clear its memory and it's extremely foolhardy to assume that it will. calloc() must clear the area it returns, or it's broken. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4
jimp@cognos.uucp (Jim Patterson) (01/10/89)
In article <17067@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: > I've seen people who use >calloc to zero their allocated arrays or structures assume that >"all bits zero" is the proper value for floating-point zero - >definitely not true on all machines. I'm compiling a list of such machines, but it's still empty. Can you enlighten us as to what some of these machines are? Do they have C compilers? Is all-bits-zero actually invalid (i.e. will cause a trap of some sort), or is it just not the "preferred" representation of zero? (I suspect that many BCD floating-point implementations won't even bother to check in the interests of efficiency, and so will end up getting it right anyways). I also agree that zero-filled memory isn't (maximally) portable, but I still don't know what machines it's not portable to. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/13/89)
In article <5003@aldebaran.UUCP> jimp@cognos.UUCP (Jim Patterson) writes: >I also agree that zero-filled memory isn't (maximally) portable, but I >still don't know what machines it's not portable to. Mark Brader has pointed out that the pANS imposes sufficient requirements on integers of all kinds that calloc() will properly initialize them too. Although ones-complement has -0, all-zero bits is +0, a valid zero value. The same is true of IEEE floating-point; there is a -0.0 but all-zero bits happens to be +0.0, a valid zero value. I think I've seen floating-point implementations where all-zero bits is not a valid representation of a zero value, but I don't recall where. (It is not required by the pANS.) The main culprit is null pointers, since there have been implementations where a null pointer was most conveniently represented by some pattern other than all-zero bits. None of this hides that fact that calloc() is a kludge.