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
17  4889 
rihad <ri***@mail.r u> 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
"astonishin g results" (to quote the C Rationale) when working with
other types. Thus I stay away from using it at all.
HTH
Regards
--
Irrwahn
(ir*******@free net.de)
"rihad" <ri***@mail.r u> wrote in message
news:ai******** *************** *********@4ax.c om... 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>
"rihad" <ri***@mail.r u> wrote in message
news:ai******** *************** *********@4ax.c om... 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>
"Peter Pichler" <pi*****@pobox. sk> wrote: "rihad" <ri***@mail.r u> 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
(ir*******@free net.de)
Irrwahn Grausewitz wrote:
"Peter Pichler" <pi*****@pobox. sk> wrote:
"rihad" <ri***@mail.r u> 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.
-- Er*********@sun .com
Eric Sosman <Er*********@su n.com> wrote: Irrwahn Grausewitz wrote:
"Peter Pichler" <pi*****@pobox. sk> wrote:
>"rihad" <ri***@mail.r u> 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
(ir*******@free net.de)
Irrwahn Grausewitz <ir*******@free net.de> wrote in message news:<ve******* *************** **********@4ax. com>... Eric Sosman <Er*********@su n.com> wrote:
Irrwahn Grausewitz wrote:
"Peter Pichler" <pi*****@pobox. sk> wrote:
>"rihad" <ri***@mail.r u> 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
On Wed, 29 Oct 2003 22:04:16 +0100, Irrwahn Grausewitz
<ir*******@free net.de> wrote in comp.lang.c: rihad <ri***@mail.r u> 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
"astonishin g 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.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Jack Klein <ja*******@spam cop.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
(ir*******@free net.de) This thread has been closed and replies have been disabled. Please start a new discussion. | |
