struggling to use calloc and realloc

[dagger]

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>

int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));

printf( "initial size (1 char) = %d\n", sizeof(ptr) );

ptr = (char *) realloc(ptr, sizeof(char)*10);

printf( "new size (10 chars) = %d\n", sizeof(ptr) );

return 0;
}
and yet when I run it I get a size of 4 for each printf even though
initially I allocated only the size of 1 char, and after reallocation there
should be room for 10 bytes...? Or where am I making a mistake in my
reasoning?

Thanks for any help :)

[Dave Vandervies]

In article <3f********@news1.mweb.co.za>, dagger <fe****@mweb.co.za> wrote:

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:
[trimmed mercilessly] char *ptr;
printf( "initial size (1 char) = %d\n", sizeof(ptr) );
printf( "new size (10 chars) = %d\n", sizeof(ptr) ); and yet when I run it I get a size of 4 for each printf even though
initially I allocated only the size of 1 char, and after reallocation there
should be room for 10 bytes...? Or where am I making a mistake in my
reasoning?

sizeof(ptr) gives you the size of the pointer (and getting 4 for that
means you're running the program on a machine where pointers are 4 bytes
wide, which in this day and age suggests a desktop machine running a
32-bit operating system).
There's no way to get back the size of the memory a pointer points to;
"sizeof *ptr" will give the size of one of whatever type ptr points at,
but (especially for memory obtained from malloc and its friends) your
code needs to keep track of how many of those it has space for itself.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Yes, I suppose it could if it really wanted. I stand corrected. Of course,
I'd question such a compiler's morals and drinking habits...
--Richard Heathfield in comp.lang.c

[Servé Lau]

"dagger" <fe****@mweb.co.za> wrote in message
news:3f********@news1.mweb.co.za...

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>
Didn't you get a warning? For realloc and calloc you need stdlib.h too.
int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));
Ah, you didn't get a warning because of the cast, don't cast the return
value of the alloc functions.
printf( "initial size (1 char) = %d\n", sizeof(ptr) );
sizeof(ptr) is the same as sizeof(char *), on your system sizeof(char *) is
4 bytes.
and yet when I run it I get a size of 4 for each printf even though
initially I allocated only the size of 1 char, and after reallocation there should be room for 10 bytes...? Or where am I making a mistake in my
reasoning?

sizeof gives the size of the variable itself, not the size of its value.

You wouldn't expect this either.

int x = 100;
if (sizeof x == 100) false ot true?

[Christopher Benson-Manica]

dagger <fe****@mweb.co.za> spoke thus:

#include <stdio.h>
int main() {
char *ptr;
ptr = (char *) calloc(1, sizeof(char)); ^^^^^^^^
The cast isn't needed, and will hide helpful compiler warnings should
you have the misfortune to forget to include stdio.h. You should
check that the allocation succeeded before continuing. Why not just
use malloc()? And you might want to do

malloc( sizeof(*ptr) );
printf( "initial size (1 char) = %d\n", sizeof(ptr) );
ptr is a pointer to a character. sizeof(ptr) is the space required
by such an entity; on your implementation, it happens to be four
bytes. This number has no relation to how many bytes of allocated
memory, if any, ptr points to.
ptr = (char *) realloc(ptr, sizeof(char)*10);
Again, lose the cast. If the original allocation succeeds, but this
one fails, the memory you originally allocated is now gone forever.
Make sure you can free() what you allocated in this event:

char *ptr, *tmp;

ptr=malloc( sizeof(*ptr) );
tmp=ptr;
ptr=realloc( ptr, 10*sizeof(*ptr) );
if( !ptr ) {
free( tmp ); /* tmp pointed at the memory originally malloc()'ed,
and that memory is now freed */
/* go on with life */
}
else {
/* do what you want with ptr */
}
printf( "new size (10 chars) = %d\n", sizeof(ptr) );

Same error as above.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Christopher Benson-Manica <at***@nospam.cyberspace.org> spoke thus:

ptr = (char *) calloc(1, sizeof(char));

The cast isn't needed, and will hide helpful compiler warnings should
you have the misfortune to forget to include stdio.h. You should

^^^^^^^

Of course, what would a post from me be like without some silly error
or other? This is, of course, meant to be stdlib.h. I need a post
preprocessor to catch these nasssties...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[nrk]

dagger wrote:

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>

int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));

printf( "initial size (1 char) = %d\n", sizeof(ptr) );

ptr = (char *) realloc(ptr, sizeof(char)*10);

printf( "new size (10 chars) = %d\n", sizeof(ptr) );

return 0;
}
and yet when I run it I get a size of 4 for each printf even though
initially I allocated only the size of 1 char, and after reallocation
there
should be room for 10 bytes...? Or where am I making a mistake in my
reasoning?

Thanks for any help :)

sizeof operator determines the size of the type of its operand. In this
case the type of the operand (ptr) is char *, and the size of a char * on
your machine happens to be 4, which is what's being printed. sizeof will
not tell you how many valid bytes ptr is pointing to (that is, it won't
tell you what was allocated using calloc/malloc/realloc). This information
cannot be extracted from the pointer. You need to keep track of the
allocated size in a separate variable.

-nrk.

[Kevin Goodsell]

dagger wrote:

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>

int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));
A few notes here: first, sizeof(char) is a fancy way of writing 1.
Second, calloc() is not a useful as it seems. Strictly speaking, it may
not give the objects you allocate the value you expect. This is
particularly true for floating point and pointer types. I need to check
the standard to be sure, but I've been told that all-bits-zero is not
guaranteed to be the representation of 0 for any type other than the
character types.

Finally, casting the return from malloc & friends is not recommended,
and your example seems to demonstrate one of the reasons why. You forgot
to #include <stdlib.h>, which means that there is no prototype in scope
for calloc. This in turn means that the compiler assumed (incorrectly) a
return type of int. ints and pointers may not be returned the same way,
so the pointer that calloc returned might be lost, and ptr might be
assigned garbage. Without the cast, the compiler would have been
required to warn you about the conversion from int to a pointer. With
the cast, there is no such guarantee.

Consider using the comp.lang.c-approved idiom for calling malloc & friends:

ptr = calloc(1, sizeof *ptr);

This has number of advantages. The most important are that it doesn't
mask the error mentioned above, it's largely self-maintaining if the
type of ptr changes (for example, of you later choose to support
internationalization using the type wchar_t instead of char), and it's
more difficult to screw up than other idioms.

printf( "initial size (1 char) = %d\n", sizeof(ptr) );
There are at least 2 apparent problems here. First, you seem to be
expecting sizeof to tell you how many characters you've allocated. It
cannot do that. sizeof is purely a compile-time construct. Here it will
give the size of the pointer ptr. If you want the size of a dynamically
allocated object, you need to keep track of it yourself.

The other problem is that you are using the wrong format specifier. %d
can never be an appropriate format specifier for type size_t. %d is ONLY
for type (signed) int. size_t cannot be an alias for (signed) int
because size_t must be unsigned.

Keep in mind that printf() is stupid. It can't determine the types of
the objects you pass to it. It relies completely on you telling it what
the types are. If you lie, all bets are off. Stack corruption leading to
a program crash or worse is a likely result. Always double-check your
format strings.

For size_t, you can cast to unsigned long and print using %lu. This is
mostly safe, but could potentially give incorrect results in C99, if the
size_t value exceeds the range of unsigned long.

ptr = (char *) realloc(ptr, sizeof(char)*10);
This is not a safe way of using realloc. If it fails and returns NULL,
you leak whatever memory you had already allocated. To realloc safely,
store the result into a temporary pointer, then assign into your
original pointer only if the result is non-NULL.

Also, all the notes about calloc apply here as well (except that realloc
doesn't initialize the bytes to all-bits-0).

printf( "new size (10 chars) = %d\n", sizeof(ptr) );
Same problems as the previous printf().

return 0;
}
and yet when I run it I get a size of 4 for each printf even though
initially I allocated only the size of 1 char, and after reallocation there
should be room for 10 bytes...? Or where am I making a mistake in my
reasoning?

Yes. You are printing the sizeof a pointer, not a dynamically allocated
object. C provides no way of determining the size of a dynamically
allocated object, post-allocation.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Christopher Benson-Manica]

Kevin Goodsell <us*********************@neverbox.com> spoke thus:

all-bits-zero is not
guaranteed to be the representation of 0 for any type other than the
character types.

It may be a trap representation for integer types, yes?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Kevin Goodsell]

Christopher Benson-Manica wrote:

Kevin Goodsell <us*********************@neverbox.com> spoke thus:

all-bits-zero is not
guaranteed to be the representation of 0 for any type other than the
character types.

It may be a trap representation for integer types, yes?

I think I've heard conflicting reports from different experts, or
possibly I've misunderstood some of what I've heard. It's one of those
things I've been meaning to look up for myself, but I'm afraid it'll
take me hours to find and decrypt all the relevant sections. :/

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Alex]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Kevin Goodsell <us*********************@neverbox.com> spoke thus:

all-bits-zero is not
guaranteed to be the representation of 0 for any type other than the
character types.

It may be a trap representation for integer types, yes?

Signed integer types. Yes.

Alex

[Alex]

Alex <al*******@hotmail.com> wrote:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Kevin Goodsell <us*********************@neverbox.com> spoke thus:

all-bits-zero is not
guaranteed to be the representation of 0 for any type other than the
character types.

It may be a trap representation for integer types, yes?

Signed integer types. Yes.

No!

I should have read the question first.

All bits ONE can be a trap representation in one's complement.

Alex

[Richard Heathfield]

dagger wrote:

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>
OH NO! You forgot to get yourself a prototype for calloc and realloc. You
can get these most simply by doing this:

#include <stdlib.h>

int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));
If you hadn't added this cast, you would have got a very useful diagnostic.
Note that (provided you remember to #include <stdlib.h>) the above is
functionally equivalent to:

ptr = calloc(1, sizeof *ptr);

which is rather neater, easier to type, and easier to maintain.
printf( "initial size (1 char) = %d\n", sizeof(ptr) );

You are misinterpreting the result of the sizeof operator. It yields the
size of the /pointer/, not the size of the thing to which it points.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"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, C books, etc: http://users.powernet.co.uk/eton

[Kevin Goodsell]

Alex wrote:

Alex <al*******@hotmail.com> wrote:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

It may be a trap representation for integer types, yes?

Signed integer types. Yes.

No!

I should have read the question first.

All bits ONE can be a trap representation in one's complement.

You seem to be implying that all-bits-0 may not be a trap representation
for any integer type. If I am misunderstanding, please clarify.
Otherwise, I'd be interested in how you justify this claim. My reading
of the standard so far strongly suggests that any non-character integer
type can have padding bits, and that those bits can be used to form a
trap representation. Furthermore, it does not specify what values these
padding bits take in any circumstance, and as far as I've seen does not
specify that all-padding-bits-0 (and all value bits "don't cares")
cannot be a trap representation.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Martin Ambuhl]

dagger wrote:

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>
You forgot
#include <stdlib.h>

int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));
I think you mean
ptr = calloc(1,1);
or
ptr = malloc(1);
or
ptr = calloc(1, sizeof *ptr);
or
ptr = malloc(*ptr);
Your cast serves no useful function; all it does is mask your error in
failing to #include <stdlib.h>.
sizeof(char) is 1 by definition. The 3rd and 4th options above are in case
the type of ptr should be changed later to some other kind of pointer.
Calling calloc() instead of malloc() when you don't need to initialize the
allocated array to "all bit zero" is wasteful.
Failing to check whether malloc(), calloc(), or realloc() succeeded is a
severe design error.

printf( "initial size (1 char) = %d\n", sizeof(ptr) );
This tells you what the size of a pointer to char is, so should be rewritten
printf("Size of pointer to char is %u\n", (unsigned) sizeof ptr);
Since sizeof yields a size_t, an unsigned integer (not necessarily an
unsigned int), a cast should always be used unless you have the new C99
specifier modifiers "%zu" and family. It would be safer to use "%lu" with
(unsigned long) or "%llu" with (unsigned long long) rather than plain "%d"
or "%u".
ptr = (char *) realloc(ptr, sizeof(char)*10);
See comments on the calloc() call.
printf( "new size (10 chars) = %d\n", sizeof(ptr) );
See comments on the previous printf(). You are _still_ printing the size
of a pointer to char.
return 0;
}

All of this is covered in the FAQ. You should learn to check the FAQ
always before posting.
--
Martin Ambuhl

[Martin Ambuhl]

Servé Lau wrote:

"dagger" <fe****@mweb.co.za> wrote in message
news:3f********@news1.mweb.co.za...

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>

Didn't you get a warning? For realloc and calloc you need stdlib.h too.

His casting the return values from realloc and calloc would, for many
compilers, supress any warning. And make sure that his code was wrong, too.

--
Martin Ambuhl

[Randy Howard]

In article <br**********@sparta.btinternet.com>,
do******@address.co.uk.invalid says...

printf( "initial size (1 char) = %d\n", sizeof(ptr) );

You are misinterpreting the result of the sizeof operator. It yields the
size of the /pointer/, not the size of the thing to which it points.

Note also that it returns a size_t, which is not guaranteed to fit in
the "%d" specified in the printf() call.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com

[Irrwahn Grausewitz]

Kevin Goodsell <us*********************@neverbox.com> wrote:

Christopher Benson-Manica wrote:

Kevin Goodsell <us*********************@neverbox.com> spoke thus:

all-bits-zero is not
guaranteed to be the representation of 0 for any type other than the
character types.

It may be a trap representation for integer types, yes?

I think I've heard conflicting reports from different experts, or
possibly I've misunderstood some of what I've heard. It's one of those
things I've been meaning to look up for myself, but I'm afraid it'll
take me hours to find and decrypt all the relevant sections. :/

I recall there is this Defect Report #263 filed:
( http://anubis.dkuug.dk/jtc1/sc22/wg1...ocs/dr_263.htm )

[ idiomatic memset(..., 0, ...) and calloc examples ]

Suggested[1] Technical Corrigendum

Append to 6.2.6.2#5:

For any integer type, the object representation where all the
bits are zero shall be a representation of the value zero in
that type.

[1] The last subheading in this DR should read: "Proposed
Technical Corrigendum", checked with comp.std.c recently.
Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html

[Kevin Goodsell]

Irrwahn Grausewitz wrote:

I recall there is this Defect Report #263 filed:
( http://anubis.dkuug.dk/jtc1/sc22/wg1...ocs/dr_263.htm )

[ idiomatic memset(..., 0, ...) and calloc examples ]

Suggested[1] Technical Corrigendum

Append to 6.2.6.2#5:

For any integer type, the object representation where all the
bits are zero shall be a representation of the value zero in
that type.

[1] The last subheading in this DR should read: "Proposed
Technical Corrigendum", checked with comp.std.c recently.

So what is the status of this report? Is it accepted as a defect? I'm
not familiar with how the C committee handles defect reports, but C++
defects are usually given a status that indicates if it has been
accepted (or rejected) as a defect and what plans are in the works to
fix it. I don't see anything like that on the page you linked.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Randy Howard wrote:

In article <br**********@sparta.btinternet.com>,
do******@address.co.uk.invalid says...

printf( "initial size (1 char) = %d\n", sizeof(ptr) );

You are misinterpreting the result of the sizeof operator. It yields the
size of the /pointer/, not the size of the thing to which it points.

Note also that it returns a size_t, which is not guaranteed to fit in
the "%d" specified in the printf() call.

size_t is guaranteed NOT to fit %d... unless size_t happens to promote
to int, which is probably unlikely.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Keith Thompson]

Kevin Goodsell <us*********************@neverbox.com> writes:

Randy Howard wrote:

In article <br**********@sparta.btinternet.com>,
do******@address.co.uk.invalid says...

printf( "initial size (1 char) = %d\n", sizeof(ptr) );

You are misinterpreting the result of the sizeof operator. It yields the
size of the /pointer/, not the size of the thing to which it points.

Note also that it returns a size_t, which is not guaranteed to fit in
the "%d" specified in the printf() call.

size_t is guaranteed NOT to fit %d... unless size_t happens to promote
to int, which is probably unlikely.

It depends on what you mean by "fit". On many systems, size_t happens
to be the same size as int (say, 32 bits), and the following:

printf("sizeof(foo) = %d\n", sizeof(foo));

is likely to work as expected as long as sizeof(foo) doesn't exceed
INT_MAX (assuming an appropriate declaration of foo, of course).

Having said that, it's still undefined behavior; working as expected
is just one of the infinitely many possible results of undefined
behavior. To avoid undefined behavior, you can do one of the
following:

/* Approach 1 */
printf("sizeof(foo) = %d\n", (int)sizeof(foo));

which will work if you happen to know that sizeof(foo) will never
exceed INT_MAX; or

/* Approach 2 */
printf("sizeof(foo) = %lu\n", (unsigned long)sizeof(foo));

which is guaranteed to work in C90, but could conceivably fail in C99
if size_t is bigger than unsigned long and sizeof(foo) > ULONG_MAX; or

/* Approach 3 */
printf("sizeof(foo) = %zu\n", sizeof(foo));

which will work in C99 (more precisely, if your C library's printf
implementation supports the 'z' length modifier), but not in C90.

In general, approach 2 is better than approach 1, and is unlikely to
fail in practice.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

[Keith Thompson]

Martin Ambuhl <ma*****@earthlink.net> writes:

dagger wrote:

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.
As an example the code snippet:
#include <stdio.h>

You forgot
#include <stdlib.h>

int main() {
char *ptr;
ptr = (char *) calloc(1, sizeof(char));

I think you mean
ptr = calloc(1,1);
or
ptr = malloc(1);
or
ptr = calloc(1, sizeof *ptr);
or
ptr = malloc(*ptr);

Typo alert: This last should be

ptr = malloc(sizeof *ptr);

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

[Dave Vandervies]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Martin Ambuhl <ma*****@earthlink.net> writes:

ptr = malloc(*ptr);

Typo alert: This last should be

ptr = malloc(sizeof *ptr);

int i=sizeof i;
int *ptr=&i;
ptr=malloc(*ptr);
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
That amuses the warped minds of some people here, but will be little
help to you.
--Francis Glassborow in comp.lang.c

[Irrwahn Grausewitz]

Kevin Goodsell <us*********************@neverbox.com> wrote:

Irrwahn Grausewitz wrote:

I recall there is this Defect Report #263 filed: <snippage> Append to 6.2.6.2#5:
For any integer type, the object representation where all the
bits are zero shall be a representation of the value zero in
that type.

So what is the status of this report? Is it accepted as a defect? I'm
not familiar with how the C committee handles defect reports, but C++
defects are usually given a status that indicates if it has been
accepted (or rejected) as a defect and what plans are in the works to
fix it. I don't see anything like that on the page you linked.

Sorry, I should have mentioned that the status of DR#263 is
"Closed, 2002-04-18" on this page:
http://anubis.dkuug.dk/jtc1/sc22/wg1...cs/summary.htm

IIRC from a recent thread on c.s.c, this means it is approved,
but it could theoretically be reopened for review. However,
most likely, it will be published in the next Technical
Corrigendum in it's current form (re-quoted above).

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html

[Christian Bau]

In article <3f********@news1.mweb.co.za>, "dagger" <fe****@mweb.co.za>
wrote:

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>

int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));

printf( "initial size (1 char) = %d\n", sizeof(ptr) );

ptr = (char *) realloc(ptr, sizeof(char)*10);

printf( "new size (10 chars) = %d\n", sizeof(ptr) );

return 0;
}
and yet when I run it I get a size of 4 for each printf even though
initially I allocated only the size of 1 char, and after reallocation there
should be room for 10 bytes...? Or where am I making a mistake in my
reasoning?

How big is a pointer to one byte, and how big is a pointer to ten bytes?

If you don't understand the question: How much costs your car, how much
costs the license plate of your car, and how much costs a piece of paper
with the number of the license plate of your car on it? Do they all cost
the same? Why not?

[dagger]

thank you everyone for the help. I don't think I'll be struggling with this
again soon after all your helpful feedback.

Thanks you :-)

"dagger" <fe****@mweb.co.za> wrote in message
news:3f********@news1.mweb.co.za...

Hi there. I'm using C under FreeBSD with the gcc compiler and am having a
bit of trouble using the calloc and realloc calls.

As an example the code snippet:

#include <stdio.h>

int main() {

char *ptr;

ptr = (char *) calloc(1, sizeof(char));

printf( "initial size (1 char) = %d\n", sizeof(ptr) );

ptr = (char *) realloc(ptr, sizeof(char)*10);

printf( "new size (10 chars) = %d\n", sizeof(ptr) );

return 0;
}
and yet when I run it I get a size of 4 for each printf even though
initially I allocated only the size of 1 char, and after reallocation there should be room for 10 bytes...? Or where am I making a mistake in my
reasoning?

Thanks for any help :)

[Alex]

Kevin Goodsell <us*********************@neverbox.com> wrote:

Alex wrote:

Alex <al*******@hotmail.com> wrote:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

It may be a trap representation for integer types, yes?

Signed integer types. Yes.

No!

I should have read the question first.

All bits ONE can be a trap representation in one's complement.

You seem to be implying that all-bits-0 may not be a trap representation
for any integer type. If I am misunderstanding, please clarify.
Otherwise, I'd be interested in how you justify this claim. My reading
of the standard so far strongly suggests that any non-character integer
type can have padding bits, and that those bits can be used to form a
trap representation. Furthermore, it does not specify what values these
padding bits take in any circumstance, and as far as I've seen does not
specify that all-padding-bits-0 (and all value bits "don't cares")
cannot be a trap representation.

The standard does not explicitly guarantee this, but any
implementation that would generate a trap representation for
all-bits-zero would never see the light of day, if simply
for the common practice of:

int array[2];
memset(array, 0, sizeof array);

Alex

[Kevin Goodsell]

Alex wrote:

Kevin Goodsell <us*********************@neverbox.com> wrote:

You seem to be implying that all-bits-0 may not be a trap representation
for any integer type. If I am misunderstanding, please clarify.
Otherwise, I'd be interested in how you justify this claim. My reading
of the standard so far strongly suggests that any non-character integer
type can have padding bits, and that those bits can be used to form a
trap representation. Furthermore, it does not specify what values these
padding bits take in any circumstance, and as far as I've seen does not
specify that all-padding-bits-0 (and all value bits "don't cares")
cannot be a trap representation.

The standard does not explicitly guarantee this, but any
implementation that would generate a trap representation for
all-bits-zero would never see the light of day, if simply
for the common practice of:

int array[2];
memset(array, 0, sizeof array);

Yes, that does seem likely. But this being comp.lang.c we tend to
consider the letter of the standard before practical concerns. In any
case, it appears this is considered a defect now, and all-bits-zero will
be guaranteed to be a valid representation of the value 0 for all
integer types soon.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.