efficeincy ( Am I correct ?)

Discussion in 'C Programming' started by ranjeet.gupta@gmail.com, Jun 9, 2005.

  1. Guest

    Dear All

    we all are familiar with the calloc and malloc, Now we know that
    calloc does the initialisation which is not achived in the malloc
    while allocatings bytes for diffrent data types.

    Now my concern about these two are which is more efficent to use,

    To avoid any mallacisous behaviour we gernally adopt the calloc,
    anyway both the calloc and malloc allocates the bytes in continious
    memeory location. (As calloc also initalises)

    Now I suppose the malloc is more efficent with the calloc
    reason behind this is that Calloc is having the extra overhead of
    initailisaig the bytes with Zero (Default), when we just simply want
    to allocate the bytes (no need to initialise it)


    (char *) abcd = (char *)calloc (2, 100);

    above is same as
    (char *) abcd = (char *)malloc(200);
    memset(abcd, 0, 1 * 200); // system called

    Now this means that calloc is not so much efficient as compared to
    malloc due to over head.


    But see the below case that
    suppose we have to allocte the memory for the int data type
    and initialise it with Zero,

    Case 1:

    (int *) abcd = (int *)malloc(100);
    memset(abcd, 0, sizeof(int) * 100); // The user called memset()

    Case 2:
    (int *) abcd = (int *)calloc(1, 100);
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    above is equivelent to
    (int *) abcd = (int *)malloc(100);
    memset(abcd, 0, sizeof(int) * 100); // The system called memset()


    So as in case 1 we have the User called memset fuction, hence
    case 1 is inefficent with respect to the case 2, Thus making the case
    2 more efficient.


    Now Suppose we have the to allocate the memory for again int data
    type and initialise it with 2,

    Case A:

    (int *) abcd = (int *)malloc(100);
    memset(abcd, 2, sizeof(int) * 100); // The user called memset()

    Case B:

    (int *) abcd = (int *)calloc(1, 100);
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    above is equivelent to
    (int *) abcd = (int *)malloc(100);
    memset(abcd, 0, sizeof(int) * 100); // The system called memset()

    memset(abcd, 2, sizeof(int) * 100); // The usser called memset()


    So we see that Case A is efficent as compared to the CASe B
    Thus as In Case A only once the memset() is called, while in
    case B two times memset() fucntion is called. (I.e Usser and system)
    Thus Malloc is more efficent in this case.

    So this make the diffrence in the terms of the Efficency of the calloc
    and malloc,

    where we have to get the default intialiosation then always use
    calloc and where we have to use the Some specified intialisation then
    always use the malloc.

    Please Guide me as As I was trying to get the diffrence between the
    calloc and malloc .. this is what i guessed it may be a diffrence
    also. Please let me know m i correct or not or what i am missing.

    Thanks In Advance
    Ranjeet
    , Jun 9, 2005
    #1
    1. Advertising

  2. bjrnove Guest

    wrote:
    > Dear All
    >
    > we all are familiar with the calloc and malloc, Now we know that
    > calloc does the initialisation which is not achived in the malloc
    > while allocatings bytes for diffrent data types.
    >
    > Now my concern about these two are which is more efficent to use,
    >
    > To avoid any mallacisous behaviour we gernally adopt the calloc,
    > anyway both the calloc and malloc allocates the bytes in continious
    > memeory location. (As calloc also initalises)
    >
    > Now I suppose the malloc is more efficent with the calloc
    > reason behind this is that Calloc is having the extra overhead of
    > initailisaig the bytes with Zero (Default), when we just simply want
    > to allocate the bytes (no need to initialise it)
    >
    > (char *) abcd = (char *)calloc (2, 100);
    >
    > above is same as
    > (char *) abcd = (char *)malloc(200);
    > memset(abcd, 0, 1 * 200); // system called
    >
    > Now this means that calloc is not so much efficient as compared to
    > malloc due to over head.
    >
    >
    > But see the below case that
    > suppose we have to allocte the memory for the int data type
    > and initialise it with Zero,
    >
    > Case 1:
    >
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The user called memset()

    This is not right thos, but that might be a typeo. You probably wanted
    something like this:
    (int *) abcd = (int *)malloc(sizeof(int) * 100);
    memset(abcd, 0, sizeof(int) * 100);

    Another thing, the cast has no meaning since malloc returns void*.

    >
    > Case 2:
    > (int *) abcd = (int *)calloc(1, 100);
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > above is equivelent to
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The system called memset()

    No, not quite, but that is probably because of typeo's.

    (int *) abcd = (int *)calloc(100, sizeof(int));

    above is equivelent to
    (int *) abcd = (int *)malloc(sizeof(int) * 100);
    memset(abcd, 0, sizeof(int) * 100);

    Now your statement is true :).

    >
    > So as in case 1 we have the User called memset fuction, hence
    > case 1 is inefficent with respect to the case 2, Thus making the case
    > 2 more efficient.
    >
    >
    > Now Suppose we have the to allocate the memory for again int data
    > type and initialise it with 2,
    >
    > Case A:
    >
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 2, sizeof(int) * 100); // The user called memset()
    >
    > Case B:
    >
    > (int *) abcd = (int *)calloc(1, 100);
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > above is equivelent to
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The system called memset()
    >
    > memset(abcd, 2, sizeof(int) * 100); // The usser called memset()

    Again not quite (much the same as described above), but I think I get
    your point.

    Another thing is that the memset will NOT initialize the int's to 2.
    Memset will initialize each byte in the memory to two.

    >
    >
    > So we see that Case A is efficent as compared to the CASe B
    > Thus as In Case A only once the memset() is called, while in
    > case B two times memset() fucntion is called. (I.e Usser and system)
    > Thus Malloc is more efficent in this case.
    >
    > So this make the diffrence in the terms of the Efficency of the calloc
    > and malloc,
    >
    > where we have to get the default intialiosation then always use
    > calloc and where we have to use the Some specified intialisation then
    > always use the malloc.
    >
    > Please Guide me as As I was trying to get the diffrence between the
    > calloc and malloc .. this is what i guessed it may be a diffrence
    > also. Please let me know m i correct or not or what i am missing.

    Except from you code to be wrong - I pointed out a couple of errors
    above - your idea is pretty much right. You should use calloc when the
    buffer needs to be initialized to zero and malloc in all other cases.

    When it comes to memset it doesn't do what you think it does. It
    initializes all bytes in the memory buffer to the value you give it,
    but since sizeof(int) usaly are > 1 you can't use it to initialize
    int's to for example 2.

    --
    bjrnove
    bjrnove, Jun 9, 2005
    #2
    1. Advertising

  3. On 2005-06-09 10:17:14 -0400, said:

    > Dear All
    >
    > we all are familiar with the calloc and malloc, Now we know that
    > calloc does the initialisation which is not achived in the malloc
    > while allocatings bytes for diffrent data types.
    >
    > Now my concern about these two are which is more efficent to use,


    Write the code that does what you want, measure it *then* make
    decisions about what needs to be optimized.


    > To avoid any mallacisous behaviour we gernally adopt the calloc,
    > anyway both the calloc and malloc allocates the bytes in continious
    > memeory location. (As calloc also initalises)
    >
    > Now I suppose the malloc is more efficent with the calloc
    > reason behind this is that Calloc is having the extra overhead of
    > initailisaig the bytes with Zero (Default), when we just simply want
    > to allocate the bytes (no need to initialise it)


    It might be, it might not be.

    > (char *) abcd = (char *)calloc (2, 100);
    >
    > above is same as
    > (char *) abcd = (char *)malloc(200);
    > memset(abcd, 0, 1 * 200); // system called
    >
    > Now this means that calloc is not so much efficient as compared to
    > malloc due to over head.
    >
    >
    > But see the below case that
    > suppose we have to allocte the memory for the int data type
    > and initialise it with Zero,
    >
    > Case 1:
    >
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The user called memset()
    >
    > Case 2:
    > (int *) abcd = (int *)calloc(1, 100);
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > above is equivelent to
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The system called memset()
    >
    >
    > So as in case 1 we have the User called memset fuction, hence
    > case 1 is inefficent with respect to the case 2, Thus making the case
    > 2 more efficient.


    It might be, it might not be. In fact, many OS's zero all memory
    allocations anyway. On such a platform, calloc might be implemented as:

    void *calloc(size_t count, size_t size)
    {
    return malloc(count * size);
    }

    ....in which case, there'd be almost no difference in execution speed
    between malloc and calloc.

    > Now Suppose we have the to allocate the memory for again int data
    > type and initialise it with 2,
    >
    > Case A:
    >
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 2, sizeof(int) * 100); // The user called memset()
    >
    > Case B:
    >
    > (int *) abcd = (int *)calloc(1, 100);
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > above is equivelent to
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The system called memset()
    >
    > memset(abcd, 2, sizeof(int) * 100); // The usser called memset()
    >
    >
    > So we see that Case A is efficent as compared to the CASe B
    > Thus as In Case A only once the memset() is called, while in
    > case B two times memset() fucntion is called. (I.e Usser and system)
    > Thus Malloc is more efficent in this case.
    >
    > So this make the diffrence in the terms of the Efficency of the calloc
    > and malloc,
    >
    > where we have to get the default intialiosation then always use
    > calloc and where we have to use the Some specified intialisation then
    > always use the malloc.
    >
    > Please Guide me as As I was trying to get the diffrence between the
    > calloc and malloc .. this is what i guessed it may be a diffrence
    > also. Please let me know m i correct or not or what i am missing.


    If you profile the code, and find that calloc is significantly slower
    than malloc, then yes, you can change your code to use malloc when you
    plan to immediately initialize the data, and calloc when you want it
    initialized to all-zero.



    --
    Clark S. Cox, III
    Clark S. Cox III, Jun 9, 2005
    #3
  4. writes:
    > (char *) abcd = (char *)calloc (2, 100);
    >
    > above is same as
    > (char *) abcd = (char *)malloc(200);
    > memset(abcd, 0, 1 * 200); // system called


    You can't have a cast on the left side of an assignment. A cast
    yields a value, not an lvalue. If your compiler doesn't complain
    about this, you should invoke it with whatever options you need to
    make it conform more closely to the C standard.

    Assuming the declaration
    char *abcd;
    the above should be written as
    abcd = calloc(2, 100);
    or
    abcd = malloc(200);
    memset(abcd, 0, 200);

    In general, the recommended way to use malloc is, for example:

    int *ptr;
    ptr = malloc(100 * sizeof *ptr);

    Casting the result of malloc() is unnecessary and can mask errors such
    as forgetting to "#include <stdlib.h>". If your compiler complains
    about it, and you remembered the #include directive, you may be using
    a C++ compiler; either use a C compiler (possibly by invoking your
    compiler with different options) or post to comp.lang.c++. Using
    "sizeof *ptr" rather than "sizeof(int)" means you don't have to change
    the code if the type of ptr changes.

    As for malloc() vs. calloc(), malloc() is likely to be slightly
    quicker than calloc() because calloc() initializes the allocated space
    to all-bits-zero. If you *want* this initialization, you can use
    calloc() -- or you can use malloc() followed by memset() if you
    prefer. There's no reason to expect calloc() to be significantly
    faster or slower than malloc() followed by memset(); use whichever you
    prefer. But keep in mind that all-bits-zero is guaranteed to be valid
    only for integer types; for floating-point and pointer types, it may
    give you garbage.

    Also consider that the system's underlying memory allocator may also
    initialize the space to all-bits-zero, so there may be no performance
    difference between malloc() and calloc().

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jun 10, 2005
    #4
  5. Guest

    Keith Thompson wrote:
    > writes:
    > > (char *) abcd = (char *)calloc (2, 100);
    > >
    > > above is same as
    > > (char *) abcd = (char *)malloc(200);
    > > memset(abcd, 0, 1 * 200); // system called

    >
    > You can't have a cast on the left side of an assignment. A cast
    > yields a value, not an lvalue. If your compiler doesn't complain
    > about this, you should invoke it with whatever options you need to
    > make it conform more closely to the C standard.
    >
    > Assuming the declaration
    > char *abcd;
    > the above should be written as
    > abcd = calloc(2, 100);
    > or
    > abcd = malloc(200);
    > memset(abcd, 0, 200);
    >
    > In general, the recommended way to use malloc is, for example:
    >
    > int *ptr;
    > ptr = malloc(100 * sizeof *ptr);
    >
    > Casting the result of malloc() is unnecessary and can mask errors such
    > as forgetting to "#include <stdlib.h>". If your compiler complains
    > about it, and you remembered the #include directive, you may be using
    > a C++ compiler; either use a C compiler (possibly by invoking your
    > compiler with different options) or post to comp.lang.c++. Using
    > "sizeof *ptr" rather than "sizeof(int)" means you don't have to change
    > the code if the type of ptr changes.
    >
    > As for malloc() vs. calloc(), malloc() is likely to be slightly
    > quicker than calloc() because calloc() initializes the allocated space
    > to all-bits-zero. If you *want* this initialization, you can use
    > calloc() -- or you can use malloc() followed by memset() if you
    > prefer. There's no reason to expect calloc() to be significantly
    > faster or slower than malloc() followed by memset(); use whichever you
    > prefer. But keep in mind that all-bits-zero is guaranteed to be valid
    > only for integer types; for floating-point and pointer types, it may
    > give you garbage.



    when we know that all the bytes allocated by the calloc is
    initialised with the zero, so why its going to give the garbage
    values ??,

    One thing I know (not Sure as some where I read) that
    calloc sometimes carries bug as its sometimes does not terminate
    the string with '\0', How much I am may be assured on this statement
    as When I tried and expremented then I did not find the error for
    the calloc, As its also said that calloc does sometime does not
    terminate the string with '\0', So gernally preffer malloc.

    Thanks to all who particpated in the thread, to make the things
    more clear,

    Regards
    Ranjeet



    >
    > Also consider that the system's underlying memory allocator may also
    > initialize the space to all-bits-zero, so there may be no performance
    > difference between malloc() and calloc().
    >
    > --
    > Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    > San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    > We must do something. This is something. Therefore, we must do this.
    , Jun 10, 2005
    #5
  6. writes:
    > Keith Thompson wrote:

    [...]
    >> As for malloc() vs. calloc(), malloc() is likely to be slightly
    >> quicker than calloc() because calloc() initializes the allocated space
    >> to all-bits-zero. If you *want* this initialization, you can use
    >> calloc() -- or you can use malloc() followed by memset() if you
    >> prefer. There's no reason to expect calloc() to be significantly
    >> faster or slower than malloc() followed by memset(); use whichever you
    >> prefer. But keep in mind that all-bits-zero is guaranteed to be valid
    >> only for integer types; for floating-point and pointer types, it mayn
    >> give you garbage.

    >
    >
    > when we know that all the bytes allocated by the calloc is
    > initialised with the zero, so why its going to give the garbage
    > values ??,


    For a pointer or floating-point type, an all-bits-zero representation
    may be a garbage value. It's very common for a floating-point value
    0.0 to be represented as all-bits-zero, and for a null pointer also to
    be represented as all-bits-zero, but neither is guaranteed by the
    standard. If you write code that makes this assumption, it will
    probably work on most systems, but it could break at the most
    inconvenient possible moment (perhaps years from now when the code is
    ported to some new platform and the original author has moved on).

    > One thing I know (not Sure as some where I read) that
    > calloc sometimes carries bug as its sometimes does not terminate
    > the string with '\0', How much I am may be assured on this statement
    > as When I tried and expremented then I did not find the error for
    > the calloc, As its also said that calloc does sometime does not
    > terminate the string with '\0', So gernally preffer malloc.


    Doesn't terminate *what* string with '\0'? Can you give an example?

    A buffer allocated with calloc() is guaranteed to be filled with
    zeros; it's difficult to imagine any implementation getting this
    wrong.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jun 10, 2005
    #6
  7. Guest

    Keith Thompson wrote:
    > writes:
    > > Keith Thompson wrote:

    > [...]
    > >> As for malloc() vs. calloc(), malloc() is likely to be slightly
    > >> quicker than calloc() because calloc() initializes the allocated space
    > >> to all-bits-zero. If you *want* this initialization, you can use
    > >> calloc() -- or you can use malloc() followed by memset() if you
    > >> prefer. There's no reason to expect calloc() to be significantly
    > >> faster or slower than malloc() followed by memset(); use whichever you
    > >> prefer. But keep in mind that all-bits-zero is guaranteed to be valid
    > >> only for integer types; for floating-point and pointer types, it mayn
    > >> give you garbage.

    > >
    > >
    > > when we know that all the bytes allocated by the calloc is
    > > initialised with the zero, so why its going to give the garbage
    > > values ??,

    >
    > For a pointer or floating-point type, an all-bits-zero representation
    > may be a garbage value. It's very common for a floating-point value
    > 0.0 to be represented as all-bits-zero, and for a null pointer also to
    > be represented as all-bits-zero, but neither is guaranteed by the
    > standard. If you write code that makes this assumption, it will
    > probably work on most systems, but it could break at the most
    > inconvenient possible moment (perhaps years from now when the code is
    > ported to some new platform and the original author has moved on).
    >
    > > One thing I know (not Sure as some where I read) that
    > > calloc sometimes carries bug as its sometimes does not terminate
    > > the string with '\0', How much I am may be assured on this statement
    > > as When I tried and expremented then I did not find the error for
    > > the calloc, As its also said that calloc does sometime does not
    > > terminate the string with '\0', So gernally preffer malloc.

    >
    > Doesn't terminate *what* string with '\0'? Can you give an example?


    To check this I write the code

    int main () {

    char *array;
    char *array_ptr;

    int iterartion;

    array = calloc(10);


    array = "aaaa";
    array_ptr = array;

    for(iterartion = 0; iterartion < 10; ++iterartion) {
    prtintf("%d\n", *array_ptr);
    ++array_ptr;
    }

    return 0;
    }

    in this code I am geting the out put as
    97
    97
    97
    97
    0
    23
    234
    345
    2334
    42

    So according to the logic and my knowlege it should give all the
    values as 0 after the first 0 which I got the out put, But I am
    geting the junk value as i have use the calloc,

    the same case I am achivening when I use the malloc and the memset
    for Zero,

    why there is contradict of the statement. rather the out put
    should be
    97
    97
    97
    97
    0
    0
    0
    0
    0
    0

    Thanks in Advance
    Ranjeet





    >
    > A buffer allocated with calloc() is guaranteed to be filled with
    > zeros; it's difficult to imagine any implementation getting this
    > wrong.
    >
    > --
    > Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    > San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    > We must do something. This is something. Therefore, we must do this.
    , Jun 10, 2005
    #7
  8. Old Wolf Guest

    wrote:
    >
    > int main () {
    >
    > char *array;
    > char *array_ptr;
    >
    > int iterartion;
    >
    > array = calloc(10);


    This points 'array' to 10 bytes you've just calloc'd

    > array = "aaaa";


    Dar. This points 'array' to the string literal "aaaa".
    'array' is no longer pointing to the calloc'd memory
    (which you have just leaked)

    > array_ptr = array;
    >
    > for(iterartion = 0; iterartion < 10; ++iterartion) {
    > prtintf("%d\n", *array_ptr);
    > ++array_ptr;
    > }
    >
    > return 0;
    > }
    >
    > in this code I am geting the out put as
    > 97
    > 97
    > 97
    > 97
    > 0
    > 23
    > 234
    > 345
    > 2334
    > 42


    You read past the end of a string literal, so you're getting
    undefined behaviour.

    > So according to the logic and my knowlege it should give all the
    > values as 0 after the first 0 which I got the out put, But I am
    > geting the junk value as i have use the calloc,


    'array_ptr' does not point at the calloc'd memory.
    Old Wolf, Jun 10, 2005
    #8
  9. CBFalconer Guest

    wrote:
    > Keith Thompson wrote:
    >> writes:
    >> > Keith Thompson wrote:

    >> [...]
    >>>> As for malloc() vs. calloc(), malloc() is likely to be slightly
    >>>> quicker than calloc() because calloc() initializes the allocated
    >>>> space to all-bits-zero. If you *want* this initialization, you
    >>>> can use calloc() -- or you can use malloc() followed by memset()
    >>>> if you prefer. There's no reason to expect calloc() to be
    >>>> significantly faster or slower than malloc() followed by memset();
    >>>> use whichever you prefer. But keep in mind that all-bits-zero is
    >>>> guaranteed to be valid only for integer types; for floating-point
    >>>> and pointer types, it mayn give you garbage.
    >>>
    >>> when we know that all the bytes allocated by the calloc is
    >>> initialised with the zero, so why its going to give the garbage
    >>> values ??,

    >>
    >> For a pointer or floating-point type, an all-bits-zero
    >> representation may be a garbage value. It's very common for a
    >> floating-point value 0.0 to be represented as all-bits-zero, and
    >> for a null pointer also to be represented as all-bits-zero, but
    >> neither is guaranteed by the standard. If you write code that
    >> makes this assumption, it will probably work on most systems, but
    >> it could break at the most inconvenient possible moment (perhaps
    >> years from now when the code is ported to some new platform and
    >> the original author has moved on).
    >>
    >>> One thing I know (not Sure as some where I read) that
    >>> calloc sometimes carries bug as its sometimes does not terminate
    >>> the string with '\0', How much I am may be assured on this
    >>> statement as When I tried and expremented then I did not find
    >>> the error for the calloc, As its also said that calloc does
    >>> sometime does not terminate the string with '\0', So gernally
    >>> preffer malloc.

    >>
    >> Doesn't terminate *what* string with '\0'? Can you give an
    >> example?

    >
    > To check this I write the code
    >
    > int main () {
    >
    > char *array;
    > char *array_ptr;
    >
    > int iterartion;
    >
    > array = calloc(10);
    >
    > array = "aaaa";
    > array_ptr = array;
    >
    > for(iterartion = 0; iterartion < 10; ++iterartion) {
    > prtintf("%d\n", *array_ptr);
    > ++array_ptr;
    > }
    >
    > return 0;
    > }
    >
    > in this code I am geting the out put as
    > 97
    > 97
    > 97
    > 97
    > 0
    > 23
    > 234
    > 345
    > 2334
    > 42
    >
    > So according to the logic and my knowlege it should give all the
    > values as 0 after the first 0 which I got the out put, But I am
    > geting the junk value as i have use the calloc,
    >
    > the same case I am achivening when I use the malloc and the memset
    > for Zero,
    >
    > why there is contradict of the statement. rather the out put
    > should be
    > 97
    > 97
    > 97
    > 97
    > 0
    > 0
    > 0
    > 0
    > 0
    > 0


    If you hadn't changed the pointer in array, and caused a memory
    leak, it might well point to something with all zeroes in it. As
    it is, once you access things past the end of the "aaaa" array you
    are precipitating undefined behaviour.

    I am deliberately being slightly vague in the hope that you can
    figure it out from the clues, after which you will have learned
    something.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    CBFalconer, Jun 10, 2005
    #9
  10. Guest

    Old Wolf wrote:
    > wrote:
    > >
    > > int main () {
    > >
    > > char *array;
    > > char *array_ptr;
    > >
    > > int iterartion;
    > >
    > > array = calloc(10);

    >
    > This points 'array' to 10 bytes you've just calloc'd
    >
    > > array = "aaaa";

    >
    > Dar. This points 'array' to the string literal "aaaa".
    > 'array' is no longer pointing to the calloc'd memory
    > (which you have just leaked)


    Yes you are absolutely correct that i wrote the code which is
    casuing the memory leak, And this i did not checked, Thansk for this]
    Now my doubts are clear, Well I want to know how to place a check
    that I am not using the memory leak. (So that to avoid the memory
    leak accidenlty if it happens)

    Thanks
    Ranjeet

    >
    > > array_ptr = array;
    > >
    > > for(iterartion = 0; iterartion < 10; ++iterartion) {
    > > prtintf("%d\n", *array_ptr);
    > > ++array_ptr;
    > > }
    > >
    > > return 0;
    > > }
    > >
    > > in this code I am geting the out put as
    > > 97
    > > 97
    > > 97
    > > 97
    > > 0
    > > 23
    > > 234
    > > 345
    > > 2334
    > > 42

    >
    > You read past the end of a string literal, so you're getting
    > undefined behaviour.
    >
    > > So according to the logic and my knowlege it should give all the
    > > values as 0 after the first 0 which I got the out put, But I am
    > > geting the junk value as i have use the calloc,

    >
    > 'array_ptr' does not point at the calloc'd memory.
    , Jun 10, 2005
    #10
  11. writes:
    > Keith Thompson wrote:
    >> writes:

    [...]
    >> > One thing I know (not Sure as some where I read) that
    >> > calloc sometimes carries bug as its sometimes does not terminate
    >> > the string with '\0', How much I am may be assured on this statement
    >> > as When I tried and expremented then I did not find the error for
    >> > the calloc, As its also said that calloc does sometime does not
    >> > terminate the string with '\0', So gernally preffer malloc.

    >>
    >> Doesn't terminate *what* string with '\0'? Can you give an example?

    >
    > To check this I write the code
    >
    > int main () {
    >
    > char *array;
    > char *array_ptr;
    >
    > int iterartion;
    >
    > array = calloc(10);
    >
    >
    > array = "aaaa";
    > array_ptr = array;
    >
    > for(iterartion = 0; iterartion < 10; ++iterartion) {
    > prtintf("%d\n", *array_ptr);
    > ++array_ptr;
    > }
    >
    > return 0;
    > }


    No, you didn't. If you're going to post code here, *please* post the
    exact code. Cut-and-paste it; don't re-type it. (I'm assuming your
    library doesn't actually have a function called "prtintf".)

    The problem, of course, is that the assignment
    array = "aaaa";
    assigns the *address* of the string literal to the variable "array",
    losing the address of the allocated block of memory.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jun 10, 2005
    #11
  12. Aaron Gage Guest

    wrote:
    > Dear All
    >
    > we all are familiar with the calloc and malloc, Now we know that
    > calloc does the initialisation which is not achived in the malloc
    > while allocatings bytes for diffrent data types.
    >
    > Now my concern about these two are which is more efficent to use,
    >
    > To avoid any mallacisous behaviour we gernally adopt the calloc,
    > anyway both the calloc and malloc allocates the bytes in continious
    > memeory location. (As calloc also initalises)
    >
    > Now I suppose the malloc is more efficent with the calloc
    > reason behind this is that Calloc is having the extra overhead of
    > initailisaig the bytes with Zero (Default), when we just simply want
    > to allocate the bytes (no need to initialise it)
    >
    >
    > (char *) abcd = (char *)calloc (2, 100);
    >
    > above is same as
    > (char *) abcd = (char *)malloc(200);
    > memset(abcd, 0, 1 * 200); // system called
    >
    > Now this means that calloc is not so much efficient as compared to
    > malloc due to over head.
    >
    >
    > But see the below case that
    > suppose we have to allocte the memory for the int data type
    > and initialise it with Zero,
    >
    > Case 1:
    >
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The user called memset()
    >
    > Case 2:
    > (int *) abcd = (int *)calloc(1, 100);
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > above is equivelent to
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The system called memset()
    >
    >
    > So as in case 1 we have the User called memset fuction, hence
    > case 1 is inefficent with respect to the case 2, Thus making the case
    > 2 more efficient.
    >
    >
    > Now Suppose we have the to allocate the memory for again int data
    > type and initialise it with 2,
    >
    > Case A:
    >
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 2, sizeof(int) * 100); // The user called memset()
    >
    > Case B:
    >
    > (int *) abcd = (int *)calloc(1, 100);
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > above is equivelent to
    > (int *) abcd = (int *)malloc(100);
    > memset(abcd, 0, sizeof(int) * 100); // The system called memset()
    >
    > memset(abcd, 2, sizeof(int) * 100); // The usser called memset()
    >
    >
    > So we see that Case A is efficent as compared to the CASe B
    > Thus as In Case A only once the memset() is called, while in
    > case B two times memset() fucntion is called. (I.e Usser and system)
    > Thus Malloc is more efficent in this case.
    >
    > So this make the diffrence in the terms of the Efficency of the calloc
    > and malloc,
    >
    > where we have to get the default intialiosation then always use
    > calloc and where we have to use the Some specified intialisation then
    > always use the malloc.
    >
    > Please Guide me as As I was trying to get the diffrence between the
    > calloc and malloc .. this is what i guessed it may be a diffrence
    > also. Please let me know m i correct or not or what i am missing.
    >
    > Thanks In Advance
    > Ranjeet
    >


    It depends on which compiler (and or std library) you are using.

    gcc calls a function called bzero to init array to 0.

    MS VC++ uses 2 different versions of calloc: One is VERY complicated
    (and does call memset) and the other iterates a pointer over the array like:

    while ( startptr < lastptr )
    *startptr++ = 0;
    ALSO:

    Ask yourself how often you actually NEED a zero initialized array.
    Usually you will initialize the array yourself, and with different data
    in each (most) elements aswell, so I suggest using malloc

    I have written probably 250,000 lines of C over the past 7 years, and I
    think I've only used calloc a handful of times.

    Also: in Case B above, why would you use calloc if you knew you wanted
    the array initialized to 2 and not 0? This kind of illustrates my point.

    Also: unless you are writing code for embedded systems, or to run on
    other resource constrained architectures, does the extra call (or loop)
    to init array to zero really matter?

    And what if you are allocating an array of structs?
    Initializing to 0 may not make sense, so you have to use malloc, then
    init each element manually (memset won't work).

    HTH.
    Aaron Gage, Jun 10, 2005
    #12
  13. <> wrote in message
    news:...
    >
    >
    > Old Wolf wrote:
    > > wrote:
    > > >
    > > > int main () {
    > > >
    > > > char *array;
    > > > char *array_ptr;
    > > >
    > > > int iterartion;
    > > >
    > > > array = calloc(10);

    > >
    > > This points 'array' to 10 bytes you've just calloc'd
    > >
    > > > array = "aaaa";

    > >
    > > Dar. This points 'array' to the string literal "aaaa".
    > > 'array' is no longer pointing to the calloc'd memory
    > > (which you have just leaked)

    >
    > Yes you are absolutely correct that i wrote the code which is
    > casuing the memory leak, And this i did not checked, Thansk for this]
    > Now my doubts are clear, Well I want to know how to place a check
    > that I am not using the memory leak. (So that to avoid the memory
    > leak accidenlty if it happens)
    >


    One thing you could (should) have done in this case was to free() all
    malloc/calloc'ed memory once you were done with it:

    >
    > >
    > > > array_ptr = array;
    > > >
    > > > for(iterartion = 0; iterartion < 10; ++iterartion) {
    > > > prtintf("%d\n", *array_ptr);
    > > > ++array_ptr;
    > > > }


    free (array);

    > > >
    > > > return 0;
    > > > }
    > > >


    This would have almost certainly given you a SegFault, and an immediate hint
    that there was a flaw in your memory management.
    See also the comp.lang.c FAQ, questions 7.22, 7.24, and 7.31.
    http://www.eskimo.com/~scs/C-faq/top.html

    -Charles
    Charles M. Reinke, Jun 10, 2005
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim Hubberstey
    Replies:
    0
    Views:
    1,062
    Tim Hubberstey
    Jul 3, 2003
  2. joon
    Replies:
    1
    Views:
    515
    Roedy Green
    Jul 8, 2003
  3. Dan

    correct or not correct?

    Dan, Oct 2, 2003, in forum: HTML
    Replies:
    7
    Views:
    439
  4. J.Ram
    Replies:
    7
    Views:
    649
  5. froil
    Replies:
    12
    Views:
    309
    Gunnar Hjalmarsson
    Mar 2, 2006
Loading...

Share This Page