f



calloc(1,1) vs. *malloc(1)=0

To make up a proper dynamically allocated empty C string, would it suffice to
say:

  return calloc(1, 1);

or am I better off using the longer version

  char *p = malloc(1);
  if (p) *p = 0;
  return p;

? TIA

0
rihad (92)
10/29/2003 8:12:16 PM
comp.lang.c 30657 articles. 4 followers. spinoza1111 (3246) is leader. Post Follow

17 Replies
544 Views

Similar Articles

[PageSpeed] 30

rihad <rihad@mail.ru> wrote:

>To make up a proper dynamically allocated empty C string, would it suffice to
>say:
>
>  return calloc(1, 1);
>
>or am I better off using the longer version
>
>  char *p = malloc(1);
>  if (p) *p = 0;
>  return p;

Both versions may return NULL, which is not a pointer to an empty 
string.  Unless you expect the caller of your function to check for 
NULL you should take appropriate action before returning p.

As for calloc: I always have a funny feeling about this "the space 
is initialized to all bits zero" behaviour.  That isn't a problem 
when you're dealing with unsigned character entitities, but may have 
"astonishing results" (to quote the C Rationale) when working with 
other types.  Thus I stay away from using it at all. 

HTH
Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/29/2003 9:04:16 PM
"rihad" <rihad@mail.ru> wrote in message
news:ai70qvo8836ivijr2j9kk1tdvvj6kc8672@4ax.com...
> To make up a proper dynamically allocated empty C string, would it suffice
to
> say:
>
>   return calloc(1, 1);
>
> or am I better off using the longer version
>
>   char *p = malloc(1);
>   if (p) *p = 0;
>   return p;

There is no difference between those two, from C's POV.

<OT> Just out of interest, why would you want to do such a thing? :-) </OT>


0
pichlo6 (40)
10/29/2003 9:05:35 PM
"rihad" <rihad@mail.ru> wrote in message
news:ai70qvo8836ivijr2j9kk1tdvvj6kc8672@4ax.com...
> To make up a proper dynamically allocated empty C string, would it suffice
to
> say:
>
>   return calloc(1, 1);
>
> or am I better off using the longer version
>
>   char *p = malloc(1);
>   if (p) *p = 0;
>   return p;

There is no difference between those two, from C's POV.

<OT> Just out of interest, why would you want to do such a thing? :-) </OT>


0
pichlo6 (40)
10/29/2003 9:05:35 PM
"Peter Pichler" <pichlo6@pobox.sk> wrote:

>"rihad" <rihad@mail.ru> wrote in message
>>   return calloc(1, 1);

>>   char *p = malloc(1);
>>   if (p) *p = 0;
>>   return p;

>There is no difference between those two, from C's POV.

As long as char is unsigned by default, or it is signed but 
doesn't contain padding bits;  otherwise the first method might 
generate a trap representation by setting *p to all bits zero,
IIRC.

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/29/2003 10:22:59 PM
Irrwahn Grausewitz wrote:
> 
> "Peter Pichler" <pichlo6@pobox.sk> wrote:
> 
> >"rihad" <rihad@mail.ru> wrote in message
> >>   return calloc(1, 1);
> 
> >>   char *p = malloc(1);
> >>   if (p) *p = 0;
> >>   return p;
> 
> >There is no difference between those two, from C's POV.
> 
> As long as char is unsigned by default, or it is signed but
> doesn't contain padding bits;  otherwise the first method might
> generate a trap representation by setting *p to all bits zero,
> IIRC.

    That particular perversion doesn't seem to be possible
in this instance.  The Standard describes a string as being
"terminated by [...] the first null character" (7.1.1/1).
The null character is in turn defined as "a byte with all
bits set to zero" (5.2.1/2).

    Thus, the byte zeroed by calloc() is in fact the string
terminator.

-- 
Eric.Sosman@sun.com
0
Eric.Sosman (4552)
10/29/2003 10:54:38 PM
Eric Sosman <Eric.Sosman@sun.com> wrote:

>Irrwahn Grausewitz wrote:
>> 
>> "Peter Pichler" <pichlo6@pobox.sk> wrote:
>> 
>> >"rihad" <rihad@mail.ru> wrote in message
>> >>   return calloc(1, 1);
>> 
>> >>   char *p = malloc(1);
>> >>   if (p) *p = 0;
>> >>   return p;
>> 
>> >There is no difference between those two, from C's POV.
>> 
>> As long as char is unsigned by default, or it is signed but
>> doesn't contain padding bits;  otherwise the first method might
>> generate a trap representation by setting *p to all bits zero,
>> IIRC.
>
>    That particular perversion doesn't seem to be possible
>in this instance.  The Standard describes a string as being
>"terminated by [...] the first null character" (7.1.1/1).
>The null character is in turn defined as "a byte with all
>bits set to zero" (5.2.1/2).
>
>    Thus, the byte zeroed by calloc() is in fact the string
>terminator.

Yes, you're right, thanks for correcting.  

All these recent discussions about padding bits and trap 
representations made me somewhat paranoid about that matter. 

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/29/2003 11:16:21 PM
Irrwahn Grausewitz <irrwahn33@freenet.de> wrote in message news:<vei0qv09ckic8g0ovc9lrek2etts07dbb1@4ax.com>...
> Eric Sosman <Eric.Sosman@sun.com> wrote:
> 
> >Irrwahn Grausewitz wrote:
> >> 
> >> "Peter Pichler" <pichlo6@pobox.sk> wrote:
> >> 
> >> >"rihad" <rihad@mail.ru> wrote in message
> >> >>   return calloc(1, 1);
>  
> >> >>   char *p = malloc(1);
> >> >>   if (p) *p = 0;
> >> >>   return p;
>  
> >> >There is no difference between those two, from C's POV.
> >> 
> >> As long as char is unsigned by default, or it is signed but
> >> doesn't contain padding bits;  otherwise the first method might
> >> generate a trap representation by setting *p to all bits zero,
> >> IIRC.
> >
> >    That particular perversion doesn't seem to be possible
> >in this instance.  The Standard describes a string as being
> >"terminated by [...] the first null character" (7.1.1/1).
> >The null character is in turn defined as "a byte with all
> >bits set to zero" (5.2.1/2).
> >
> >    Thus, the byte zeroed by calloc() is in fact the string
> >terminator.
> 
> Yes, you're right, thanks for correcting.  
> 
> All these recent discussions about padding bits and trap 
> representations made me somewhat paranoid about that matter. 

There is also the fact that for the non-negative values of signed
types, the value bits in the corresponding unsigned type must be the
same. This, coupled with the fact that unsigned char is not padded, is
also enough to guarantee that an all zero bit representation must
represent the value 0 for all character types.

-- 
Peter
0
airia (1802)
10/30/2003 2:32:12 AM
On Wed, 29 Oct 2003 22:04:16 +0100, Irrwahn Grausewitz
<irrwahn33@freenet.de> wrote in comp.lang.c:

> rihad <rihad@mail.ru> wrote:
> 
> >To make up a proper dynamically allocated empty C string, would it suffice to
> >say:
> >
> >  return calloc(1, 1);
> >
> >or am I better off using the longer version
> >
> >  char *p = malloc(1);
> >  if (p) *p = 0;
> >  return p;
> 
> Both versions may return NULL, which is not a pointer to an empty 
> string.  Unless you expect the caller of your function to check for 
> NULL you should take appropriate action before returning p.
> 
> As for calloc: I always have a funny feeling about this "the space 
> is initialized to all bits zero" behaviour.  That isn't a problem 
> when you're dealing with unsigned character entitities, but may have 
> "astonishing results" (to quote the C Rationale) when working with 
> other types.  Thus I stay away from using it at all. 

Sigh, here we go again:

Using calloc() to allocate memory, or using memset() to put zeros into
an array, is guaranteed to produce all 0 values for:

   - signed char
   - unsigned char
   - plain char
   - any exact-width types (i.e., uint32_t, etc.) provided in an
<stdint.h> header

....and in the real world...

   - all integer types on all architectures in actual use today

What is not guaranteed is the effect on floating point types or
pointers.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
0
jackklein (3930)
10/30/2003 2:38:37 AM
Jack Klein <jackklein@spamcop.net> wrote:

<snip>
>Sigh, here we go again:

Sorry for causing annoyance.

>Using calloc() to allocate memory, or using memset() to put zeros into
>an array, is guaranteed to produce all 0 values for:
>
>   - signed char
>   - unsigned char
>   - plain char
>   - any exact-width types (i.e., uint32_t, etc.) provided in an
><stdint.h> header
>
>...and in the real world...
>
>   - all integer types on all architectures in actual use today
>
>What is not guaranteed is the effect on floating point types or
>pointers.

Copy, got it.  <hummm-click>  
Message printed and glued to my forehead. <fizzzz>
Thank you. <feeeeep> 
Over and out.  <twirrrrl>   ;-)
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/30/2003 12:01:42 PM
In <63f490f7.0310291832.2b8488dc@posting.google.com> airia@acay.com.au (Peter Nilsson) writes:

>There is also the fact that for the non-negative values of signed
>types, the value bits in the corresponding unsigned type must be the
>same. This, coupled with the fact that unsigned char is not padded, is
>also enough to guarantee that an all zero bit representation must
>represent the value 0 for all character types.

And the answer to a defect report filed against C99 makes it clear that
an all zero bit representation must represent the value 0 for all
integer types.  It's supposed to be part of TC2, when it will finally be
released.

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/30/2003 1:02:14 PM
In <ai70qvo8836ivijr2j9kk1tdvvj6kc8672@4ax.com> rihad <rihad@mail.ru> writes:

>To make up a proper dynamically allocated empty C string, would it suffice to
>say:
>
>  return calloc(1, 1);
>
>or am I better off using the longer version
>
>  char *p = malloc(1);
>  if (p) *p = 0;
>  return p;

Since calloc() achieves exactly the same thing with less code, there is
no good reason for preferring the malloc version.

When I have dynamically allocate memory for a string that I'm building
myself, I use calloc, so that I don't have to bother writing the
terminating null character (it's very easy to forget it).

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/30/2003 2:23:43 PM
Dan.Pop@cern.ch (Dan Pop) wrote:

<snip>
>And the answer to a defect report filed against C99 makes it clear that
>an all zero bit representation must represent the value 0 for all
>integer types.  

That's a good thing to know; you are most certainly referring to DR263? 

>It's supposed to be part of TC2, when it will finally be
>released.

Will TC2 be released in the near future?

(Sorry, if this OT for c.l.c)

TIA 
Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/30/2003 2:54:35 PM
In <0h92qv4s3go1u2dqjjlljq8cdbice6btta@4ax.com> Irrwahn Grausewitz <irrwahn33@freenet.de> writes:

>Dan.Pop@cern.ch (Dan Pop) wrote:
>
><snip>
>>And the answer to a defect report filed against C99 makes it clear that
>>an all zero bit representation must represent the value 0 for all
>>integer types.  
>
>That's a good thing to know; you are most certainly referring to DR263? 

Yup.

>>It's supposed to be part of TC2, when it will finally be
>>released.
>
>Will TC2 be released in the near future?

My crystal ball is out of repair, you'll have to ask in comp.std.c.

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/30/2003 4:30:37 PM
"Dan Pop" <Dan.Pop@cern.ch> wrote in message
news:bnr6tf$ofc$1@sunnews.cern.ch...
(regarding calloc vs malloc + clearing the memory manually)
> Since calloc() achieves exactly the same thing with less code, there is
> no good reason for preferring the malloc version.

Except when this would be the only calloc in the whole project. Not linking
in an extra function might save a few bytes of executable code. But then,
it might not. There is nothing in the standard to suggest one way or the
other, only my gut feeling.


0
pichlo6 (40)
10/31/2003 12:28:23 AM
On 30 Oct 2003 14:23:43 GMT, Dan.Pop@cern.ch (Dan Pop) wrote:

>When I have dynamically allocate memory for a string that I'm building
>myself, I use calloc, so that I don't have to bother writing the
>terminating null character (it's very easy to forget it).
>

Then you wish there were recalloc()? :)
0
rihad (92)
10/31/2003 8:37:05 AM
In <41iob.923$eV1.828@newsfep1-gui.server.ntli.net> "Peter Pichler" <pichlo6@pobox.sk> writes:

>"Dan Pop" <Dan.Pop@cern.ch> wrote in message
>news:bnr6tf$ofc$1@sunnews.cern.ch...
>(regarding calloc vs malloc + clearing the memory manually)
>> Since calloc() achieves exactly the same thing with less code, there is
>> no good reason for preferring the malloc version.
>
>Except when this would be the only calloc in the whole project. Not linking
>in an extra function might save a few bytes of executable code. But then,
>it might not. There is nothing in the standard to suggest one way or the
>other, only my gut feeling.

Is saving a few bytes of executable code an overriding concern for you?

If yes, a more likely scenario is that malloc and calloc are part of the
same library module (and, therefore, get loaded together), but the user 
code using malloc gets translated into more bytes of executable code ;-)

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
11/3/2003 4:06:51 PM
"Dan Pop" <Dan.Pop@cern.ch> wrote in message
news:bo5uer$dkd$4@sunnews.cern.ch...
> In <41iob.923$eV1.828@newsfep1-gui.server.ntli.net> "Peter Pichler"
<pichlo6@pobox.sk> writes:
> >"Dan Pop" <Dan.Pop@cern.ch> wrote in message
> >news:bnr6tf$ofc$1@sunnews.cern.ch...
> >(regarding calloc vs malloc + clearing the memory manually)
> >> Since calloc() achieves exactly the same thing with less code, there is
> >> no good reason for preferring the malloc version.
> >
> >Except when this would be the only calloc in the whole project. Not
linking
> >in an extra function might save a few bytes of executable code. But then,
> >it might not. There is nothing in the standard to suggest one way or the
> >other, only my gut feeling.
>
> Is saving a few bytes of executable code an overriding concern for you?
>
> If yes, a more likely scenario is that malloc and calloc are part of the
> same library module (and, therefore, get loaded together), but the user
> code using malloc gets translated into more bytes of executable code ;-)

You are quite likely right in case of malloc vs. calloc. I know about at
least
one example when I replaced printf with my own version using putchar (I only
needed to print decimal numbers. By doing that, I saved 4 kB of compiled
executable, which was _huge_ for the target platform (Z180 with 32 kB of
EPROM).


0
pichlo6 (40)
11/3/2003 6:26:21 PM
Reply: