My CS teacher asked us the following tonight.

    int *s, *t;
    s = (int *)malloc(10,sizeof(int));
    t = s;
    Does free s; and free t; do the same thing?

And the answer was 'No.'  The professor said freeing s will free ten 32-bit
values (yeah, he went machine dependent I guess) and freeing t would free
one 32-bit value.  He then went on to say that the symbol table held memory
management information for the size of s and t which allowed the system to
do this.

This sounds really fishy to me.  Taking compiler design at the same time, I
can't see how such a thing could be managed well.  Is this correct?

      s = malloc(10 * sizeof(int));

       free(s); and free(t);

   Dump your prof and find another one, if he was speaking about C.

From P.J.Plauger's library reference:
  void free(void *ptr);
If ptr is not a null pointer, the function deallocates the object whose
address is ptr; otherwise, it does nothing. You can deallocate only
objects that you first allocate by calling calloc, malloc, or realloc.

    The most important word here is _object_. The name of the variable
you are feeding to free() is not relevant; the _value_ is.

--
        Regards,
                Alex Krol
Disclaimer: I'm not speaking for CreoScitex, Creo and/or Scitex Corp.
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html

Sent via Deja.com http://www.deja.com/
Before you buy.

I think you meant either 10 * sizeof(int) or possibly calloc.

Lose that malloc cast, by the way. It's unnecessary and can hide a bug.
Use s = malloc(10 * sizeof *s) instead.

You mean free(s) and free(t). Yes, of course they do the same thing,
because t has the same value as s.

Ask him to show you the part of the ANSI C Standard which backs up his
claim. Since he's completely wrong, he won't be able to. What he's
suggesting is truly horrific.

You're right, he's wrong.

--

Richard Heathfield

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.

C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
35 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (62
to go)

This is absolutely wrong.  free() knows nothing about symbol tables; it
operates just as any other function: it uses the value passed to it.  t and s
have the same value.

--

What one knows is, in youth, of little moment; they know enough who
know how to learn. - Henry Adams

A thick skin is a gift from God. - Konrad Adenauer
__________________________________________________________
Fight spam now!
Get your free anti-spam service: http://www.brightmail.com

I was thinking about something similar to this yesterday: perhaps the
teacher meant t to be a pointer-to-POINTER-to-int, i.e. int **t and t=&s .
Then freeing t just frees a pointer to s. Freeing s frees a pointer to a
space for 10 ints.

Isn't that the case? I was trying to free a big array of
pointer-to-pointers, and decided that I had to free all the "child"
pointers first before the main, "parent" pointer.

If I'm wholly wrong, I blame the cold I'm currently suffering from, in
order to deflect the bigger flames via sympathy. Ah-choo.

J-P
--
space-time wormhole sequel THE PHILADELPHIA EXPERIMENT 2 (12.10am, Sat,
BBC1) - featuring a parallel future where the Nazis won WW2, as opposed
to, for instance, the Allies having won it, but *in a different way*

: My CS teacher asked us the following tonight.

:     int *s, *t;
:     s = (int *)malloc(10,sizeof(int));
:     t = s;
:     Does free s; and free t; do the same thing?

: And the answer was 'No.'  The professor said freeing s will free ten 32-bit
: values (yeah, he went machine dependent I guess) and freeing t would free
: one 32-bit value.  He then went on to say that the symbol table held memory
: management information for the size of s and t which allowed the system to
: do this.

: This sounds really fishy to me.  Taking compiler design at the same time, I
: can't see how such a thing could be managed well.  Is this correct?

As others have said, your professor is a moron who doesn't know enough
C to teach it. The C allocation table is used by memory locations - not
by variables. Correcting your program a little...
#include <stdlib.h>
int *s, *t;
s = malloc(10*sizeof(int));
t = s;
Then free(s); and free(t); will be absolutely, definitely, 100%, sure-
fire, you-can-bet-your-life-and-someone-other's-as-well-on-it, identical
in operation, providing you call only one of them, not both.

--

| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/

"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
   - Mika P. Nieminen

Uh, get another professor... the one you have is BROKEN.

I've seen some of the other posts in response, but none of them (pardon
me
folks) expressed the complete nature of the disfunctionality and
complete
and total lack of understanding that your instructor has regarding C,
pointers, and dynamic memory allocation.  Hence, my reply.

The symbol information for s and t would be identical in terms of their
type.
Their locations in memory, assigned by the linker, would be different.
(Unless, of course, your optimizing compiler substituted t for s
everywhere
or s for t everywhere, in which case that would be a different story,
but
not really apropos for our discussion right now, since he has obviously
shown
his ignorance thinking that t and s represent different memory).

malloc() returns an address, the value of which, at runtime, the
compiler
could not know.  And since the VALUE of 's' is an address, and 't'
accepts this value, when you call free(s) or free(t), free() will look
up
in its (table, list, implementation-dependent data structure) the VALUE
that was returned by malloc() (i.e. the address that malloc() returned)
and will use THAT information, not the symbol 's' or 't', to decide what
portion of the memory heap to free.

BTW post his email address and that of his dean, along w/ the University
information... I think some of us here might like to have a little chat
with him...  Learning C //can// be hard and confusing... we don't need
idiots spewing this kind of garbage.

In the odd mischance that you were actually confused and he DIDN'T
state the things you posted, please ignore the rant.

In the REALLY off chance that you are doing something really
super-specific
on some bizarre architecture using a non-ANSI C compiler, and that the
super-specific compiler really DOES track calls to malloc(), etc.,
because it
converts them into some strange compile-time allocation (the odds of
which
this being the case are somewhere roughly between 1:1,000,000,000 and
1:1,000,000,000,000), then I'm wrong and your prof is right.

MG

(a) SWYM. If he meant int **t, he should have said int **t, not int *t.
(b) Let's take the hypothetical case that he meant int **t; t = &s; and
see where that leads us. Now, since s is an automatic variable, and has
not itself been allocated via calloc, malloc, or realloc, passing its
address to free() invokes undefined behaviour.

...in which case, you were doing something like this:

int **t;

t = malloc(m * sizeof *t); /* allocate space for m pointers to int */
if(t != NULL)
{
  for(i = 0; i < m; i++)
  {
    t[i] = malloc(n * sizeof *t[i]);
    if(t[i] == NULL)
    {
      take appropriate error action

/* ... */

/* use the array somehow, then... */
for(i = 0; i < m; i++)
{
  free(t[i]);
free(t);

A completely different circumstance, as I think you should now be able
to see.

You're wholly wrong. Bless you. :-)

--

Richard Heathfield

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.

C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
35 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (62
to go)

Maybe he meant int ***t:

        int ***t = malloc (sizeof *t);
        *t = &s;
        [...]
        free (t);

Or maybe that's getting into the area of the sublimely ridiculous.

That's actually not true.  Pointers can be freed in any order you
wish.  It is true, however, that it is often more straightforward
to free complex data structures "bottom-up".

Ben, what isn't true? Are you saying that he's lying about the decision
he made?

He certainly can't do this:

free(t);
for(i = 0; i < m; i++)
  free(t[i]);

so he *decided* that he had to do this instead:

for(i = 0; i < m; i++)
  free(t[i]);
free(t);

The fact that his conclusion may have been incorrect is irrelevant to
the fact that this was the conclusion he reached, which is all he was
claiming.

He could save away the pointers, of course:

int **u;
u = malloc(m * sizeof *u);
if(NULL != u)
{
  memcpy(u, t, m * sizeof *u);
  free(t);
  for(i = 0; i < m; i++)
    free(u[i]);
  free(u);

but that's pretty silly (unless you have something bizarre in mind).

--

Richard Heathfield

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.

C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
35 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (62
to go)

No, I'm saying that it's not necessary to free all the child
pointers before the main pointer.  I'm saying that
        "...I had to free all the "child" pointers first..."
isn't true.

In fact, you can free the pointers in any order you want.  You
just have to make sure you don't invoke undefined behavior or
leave garbage floating around in the process.

Freeing the child pointers first, then the parent pointer, is
certainly the simplest and easiest way to do it.

Thanks to everyone for a thorough explanation!

I'm "versed" in C enough to know that my interpretation of what the
professor said is accurate, that it sounds fishy, but not knowledgeable
enough to call him on it.  I'm glad the gurus agree.  I'm armed now and
dangerous.

The course is languages.  The same prof also told us fortran 77 supports
dynamic memory (which sounds fishy too, but it's off-topic here!)

I wanted to verify the free(t) free(s) behavior with a small program.  I
was hoping I could allocate a block of integers, free the first integer,
then try to access the block backwards (last element through first
element) and get a core dump on the first element.  No such luck.  My
SunOS platform doesn't seem to want to fault.  Any idea how I can modify
this program or test this concept?

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

int main() {

    int *i, *j;
    int c;

    i = malloc(10*sizeof(int));
    j = i;

    printf("After calloc (i) = %x\n",i);
    printf("After calloc (j) = %x\n",j);
    free(i);

    printf("After free (i) = %x\n",i);
    printf("After free (j) = %x\n",j);

    printf("Try to access all elements:\n");
    for (c=9; c >= 0; c--) {
        *(i+c) = -22;
        printf("At location %x is value %d\n",i+c,*(i+c));
    }

    return 0;

OUTPUT:
sd-souza:/home/brifox/temp 25 % ./test
After calloc (i) = 20d40
After calloc (j) = 20d40
After free (i) = 20d40
After free (j) = 20d40
Try to access all elements:
At location 20d64 is value -22
At location 20d60 is value -22
At location 20d5c is value -22
At location 20d58 is value -22
At location 20d54 is value -22
At location 20d50 is value -22
At location 20d4c is value -22
At location 20d48 is value -22
At location 20d44 is value -22
At location 20d40 is value -22

Thanks!
Brian

Sent via Deja.com http://www.deja.com/
Before you buy.

Dump your teacher. malloc(3) just gives you back a pointer to a piece of
storage of the size requested (and squirrels away the size somehow),
free(3) takes a pointer and gives the memory back to the heap (using said
size).

Could be done, but makes no sense: It would just create oportunities for
errors.
--

Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

[...order of freeing of blocks issue...]

Obviously I've confused everyone here on just what the hell I'm
talking about, so I'll try to start over.  My general point is,
you can free things in whatever order you want.  It's just that
much of the time the most convenient way is bottom-to-top.
Theoeretically, you can take all of the pointers you want to
free, stuff them all into an array of void * pointers, shuffle
the array randomly, and free them in that order.  You'd never
really want to do that, of course, unless you were stress-testing
a memory allocator.

I still don't get it (though I'm not claiming advanced expertise).
Suppose I do, for example:

  int i;
  char **foo;

  foo = malloc(10 * sizeof(char *));
  for (i=0; i<10; i++) foo[i] = malloc(32);

To make space for 10 strings of 31 characters.  Now I want to
deallocate.  My (possibly redundant) approach has been to say:

  for (i=0; i<10; i++) free(foo[i]);
  free(foo);

Now some people seem to be saying that the first line immediately
above is indeed redundant: I can just free foo, without bothering
about the foo[i]'s, and there's no memory leak.  But you seem to be
saying that I could free foo, and /then/ continue to free the
foo[i]'s, if I had a mind to.  Is that (any of it!) right?

Allin Cottrell.