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 :)

[Keith Thompson]

Martin Ambuhl <ma*****@earthl ink.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_Keit h) 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.or g>,
Keith Thompson <ks***@mib.or g> wrote:

Martin Ambuhl <ma*****@earthl ink.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************ *********@never box.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*******@free net.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********@new s1.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************ *********@never box.com> wrote:

Alex wrote:

Alex <al*******@hotm ail.com> wrote:

Christophe r Benson-Manica <at***@nospam.c yberspace.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 misunderstandin g, 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************ *********@never box.com> wrote:

You seem to be implying that all-bits-0 may not be a trap representation
for any integer type. If I am misunderstandin g, 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.