can i access 'p' even after free(p);

[Nick Austin]

I hope you don't mind me butting in, but I have an issue that seems
somewhat related... I'm implementing a variable-length array/stack,
and free() is giving me some interesting issues. It looks something
like this...

What is in "vararray.h"

/* Just including this for clarity */
void va_init( va_vararray v )

How is va_vararray declared? I assume that it is a typedef.

{
v->size = INITIAL_SIZE;

Ah. For this to be valid I guess that va_vararray is typedefed
as a pointer to a structure.

v->index = 0;
v->contents = malloc( INITIAL_SIZE * sizeof( va_ptr ) );
}

int main()
{
va_vararray v;

In which case, based on my assumptions, this just defines a pointer
to a structure. Memory for the structure itself is never allocated.

Therefore, assuming that va_vararray is a pointer, you need to add:

v = malloc( sizeof *v );

va_init( v );
printf( "Malloc'd: %x\n", (int) v->contents );
printf( "Doing stuff...\n" );

/* Pushes and pops a few elements as a test --no array-expansion
happening,
yet, no further malloc()'s called. */

printf( "Freeing...\n" );
free( v->contents );
printf( "Freed\n" );

return 0;
}

Nick.

 

[bd]

Hi, guys. I am new to C. Although I have read the faq, but I am not sure
I get the void pointer stuff. So could you read on and see if what I say
is correct?

So what Joona said means:
1. ANSI C use (void *) as a generic pointer type, and no cast is necessary
is necessary when a (void*) is assigned to a pointer to any particular
type.
Right.

2. malloc() is declared in stdio.h. It returns a (void*) and it is
guaranteed
to be aligned properly so it can be assigned to a pointer to any type.

It's in stdlib.h.

3. If stdio.h is not #included or properly declared, malloc() is view as a
function with an int return value, so there will be a problem when I write
int *p; p = malloc( sizeof(int) );

Any non-prototyped function is considered to return int and take whatever
you passed in. This can be a problem, as malloc's prototype is:
void *malloc(size_t);
And if you do:
char *foo = malloc(42);
Then 42 may be considered an int, which may be a different size or
representation than size_t. Also, int may not be passed in the same way as
char *.

And one more thing. The course project I am working on comes with an
example program that we can fill the blanks in. It uses calloc() but
instead
of stdio.h, it #includes <malloc()>. Is <malloc.h> a header file in ANSI
standard?

malloc.h is a non-standard header - you should use stdlib.h instead.

 

[bd]

Hi. I read the faq. The only thing I can find about casting pointer
returned from malloc() is
"Under ANSI/ISO Standard C, these casts are no longer necessary."
in http://www.eskimo.com/~scs/C-faq/q7.7.html

I wonder if there is any drawbacks of casting a (void*) pointer to a
specific
type it is assigned to?

If you had forgotten to #include <stdlib.h>, you'd get a diagnostic due to
the assignment from int to int *. However, with an explicit cast the
diagnostic is suppressed.

 

[Irrwahn Grausewitz]

You have just changed the members of a local copy of an va_vararray
struct (whatever it looks like, wherever it has been declared) and
forget everything on return.

Double dreaded. I noticed (after reading Nick's reply) that I took the
'->' for '.'s! So, you have hidden a pointer to a struct behind a
typedef - one good example of bad coding style. Thus the problem is
that you failed to allocate memory for 'v' to point to. However, my
remarks about UB still hold true.

<SNIP>

Regards

Irrwahn

 

[Jack Klein]

Well, mostly because it *does* initialize each byte of the allocated
memory to zero. That involves visiting every byte in the allocated
block. That means the time-complexity of memory allocation jumps
from roughly O(1) to O(N), instantly. That's *very* inefficient,
compared to using the regular malloc() for everything.
And since all-bits-zero doesn't have any useful semantic value for
*most* data types, the "initialization" doesn't save the programmer
any time, either.

Most??? Chapter and verse, please. Can you actually name one
implementation in current production where any unsigned integer type
has padding bits? Because for any implementation which does not have
padding bits in any of its unsigned integer types, all-bits-0 is
required to be a valid representation of 0 in all integer types.

Additionally, I hate calloc() because it takes two arguments where
one argument would do fine. That's just silly.

-Arthur

Actually, I don't use calloc() often, but I guarantee you that it is
appropriate when I do.

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

 

[Jack Klein]

The functions malloc, calloc, realloc and free require <stdlib.h>. Most
likely, your compiler has <stdlib.h> including <malloc.h>. Some

What makes you say that? There is no standard header named

programmers will #include <malloc.h> because it will save them a few

Programmers who include a header named "malloc.h" will find their
programs non-portable.

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

 

[Richard Bos]

Correct me if I'm wrong here, but what's stopping malloc() from also
initialising every byte to 0?

Market forces. Making your malloc() O(N) instead of O(1) isn't going to
endear you to your customers.

Richard

 

[Richard Bos]

Most??? Chapter and verse, please. Can you actually name one
implementation in current production where any unsigned integer type
has padding bits?

Implementations are unimportant - Arthur was talking about _semantic_
value, which, IYAM, means "in the abstract machine". All-bits-zero may
happen to be value 0 for floats and pointers, too, on your system, but
relying on this is simply bad coding practice.

Richard

 

[Joona I Palaste]

Market forces. Making your malloc() O(N) instead of O(1) isn't going to
endear you to your customers.

Because any particular computer architecture has a finite amount of
memory, it is trivial to make malloc() work in O(1) time, no matter
what it does.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola

 

[Jack Klein]

Implementations are unimportant - Arthur was talking about _semantic_
value, which, IYAM, means "in the abstract machine". All-bits-zero may
happen to be value 0 for floats and pointers, too, on your system, but
relying on this is simply bad coding practice.

Richard

Of course there's a DR about this...

Guaranteed that for any of:

char, signed char, unsigned char

....and (if provided):

int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t,
uint_64t, and any other exact width integer type specified in a
<stdint.h> header

....calloc() or memset() with a second argument of 0 will set the
contents of an array of signed or unsigned integers of this type to
all valid representations of the value 0.

In fact, despite the fact that the standard still allows, mention of
platforms with integer types with padding bits or trap representations
or even non 2's complement representations is simply pedantry these
days. I waste absolutely no effort on even pondering portability to
such platforms.

I do a lot of work where CHAR_BIT > 8 (embedded digital signal
processors), and in fact literally today at work I was writing code
for a DSP where CHAR_BIT is 16 and char, short, and int all share the
same representation. In the past I've worked with CHAR_BIT is 24 and
32. My chapter of C Unleashed contained a lot of bit fiddling and
shifting routines, and only assumed that CHAR_BIT >= 8. All that code
would work equally well on any of these platforms.

But frankly worrying about non 2's complement representations, or
integers with padding bits or trap representations, is just too silly
for to be worth the effort.

Once there were mastodons and saber tooth tigers, but they are extinct
now too.

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