myfree(p)

[temper3243]

Hi,

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .


Does it have any speed overhead because of assignment.

Someone (maybe gordon burditt) once said that pointers can be copied,
so it fails. I didn't quite understand that.

 

[Clark S. Cox III]

Hi,

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .


Does it have any speed overhead because of assignment.

Someone (maybe gordon burditt) once said that pointers can be copied,
so it fails. I didn't quite understand that.

void * p1 = malloc(42);
void * p2 = p1;
myfree(p1);

myfree can't possibly set all of the pointers that also point to the
same block of memory to NULL.

 

[matevzb]

Hi,

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .

In addition to what Clark mentioned, "p" is evaluated twice, so e.g.
myfree(p++) does more than it seems.

 

[Chris Dollin]

What is wrong with #define myfree(p) {free(p),p=NULL; }

(a) it assumes there's only one variable containing the pointer
you free. This is often not true.

(b) it assumes that `p` is an lvalue, ie it's assignable-to. This
need not be true.

(c) it assumes that `p` has no side-effects. This need not be
true.

(d) it assumes that the user isn't going to put a `;` after the
`myfree(whatever)` call. This is very likely not true.

Conclusion: /don't do that/. It's pointless, wrong, and incorrect.
Put your effort somewhere more useful.

 

[Bryan]

Hi,

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .

Does it have any speed overhead because of assignment.

Someone (maybe gordon burditt) once said that pointers can be copied,
so it fails. I didn't quite understand that.

If the value passed to the macro has a side-effect then you'll get
some odd behaviour. This code should demonstrate a Bad Thing
happening.

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

#define myfree(p) {free(p),p=NULL; }

int main(void)
{

char *SomeStrings[6] = {0};
char **FreePtr = NULL;
int i = 0;

/* Allocate a bunch of storage */
for(i = 0; i < sizeof SomeStrings / sizeof *SomeStrings - 1; ++i)
{
SomeStrings = malloc(42);
fprintf(stdout, "allocated %p\n", (void *)SomeStrings);
}

/* free a bunch of storage */
FreePtr = SomeStrings;
while(*FreePtr)
{
fprintf(stdout, "freeing %p\n", (void *)*FreePtr);
myfree(*FreePtr++);
}
}

 

[Richard Tobin]

In addition to what Clark mentioned, "p" is evaluated twice, so e.g.
myfree(p++) does more than it seems.

I don't think myfree(p++) can ever make sense. myfree(*p++) might.

There are also cases such as myfree(p-sizeof(int)) - where you
have a pointer to the interior of a malloc()ed area - in which
the NULL assignment would not even be syntactically correct.

Another problem is const pointers, for example:

char *const p=malloc(1);
myfree(p);

-- Richard

 

[matevzb]

I don't think myfree(p++) can ever make sense. myfree(*p++) might.

Yes of course, sorry about that. It seems I'm not making any sense
today in general...

 

[Malcolm McLean]

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .

As a general rule, don't try to mess with the language funamentals. Eg
define "begin" and "end" as curly braces, define boolean types, or redefine
free. There is a case for a free that sets its argument to null, but trying
to provide it just confuses everyone. Unless you are writing a C variant
compiler, it is not your job to try to improve the language, but to
implement program logic as clearly and as conventionally as possible.

 

[Keith Thompson]

(a) it assumes there's only one variable containing the pointer
you free. This is often not true.

(b) it assumes that `p` is an lvalue, ie it's assignable-to. This
need not be true.

(c) it assumes that `p` has no side-effects. This need not be
true.

(d) it assumes that the user isn't going to put a `;` after the
`myfree(whatever)` call. This is very likely not true.

Conclusion: /don't do that/. It's pointless, wrong, and incorrect.
Put your effort somewhere more useful.

Apart from the other problems, (d) can be addressed by changing it to:

#define myfree(p) (free(p), (p)=NULL)

It would also be better to use an all-caps name such as MYFREE, to
make it clear that it's a macro.

But in any case, it only addresses one minor issue, at the expense of
hiding free() behind a macro, which is unfriendly to programmers who
actually know how to use free() properly.

 

[Alef.Veld]

Hi,

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .

Does it have any speed overhead because of assignment.

Someone (maybe gordon burditt) once said that pointers can be copied,
so it fails. I didn't quite understand that.

What you could do, and i'm not sure this is possible and i didn't read
the replies from people
much better aware then me, is make a small library/function where each
time you wanted to
copy a pointer, your user would involve this function, and this
function would keep track of
all the pointers in some sort of list (by saving the address of the
pointer) and later do free(
0x0address) although i'm not sure free takes the address (but you
could assign this to a pointer
without allocating memory)

So you call this function when users want a copy and the function call
returns, and you call
the function (or a different one) with different arguments (or not).

If this works, you have improved your not crashing chances a bit.

 

[David T. Ashley]

Hi,

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .


Does it have any speed overhead because of assignment.

Someone (maybe gordon burditt) once said that pointers can be copied,
so it fails. I didn't quite understand that.

There is no requirement to set free()'d pointers to NULL. The program may
terminate within a few lines, or the pointer may be soon going out of scope,
so it might be wasted motion anyway.

You simply need to be clever enough not to use pointers after you've
free()'d them.

It is not uncommon in a program to see this done explicitly:

free(p);
p = NULL;

I'm not sure why you need a macro.

If you must exhibit obsessive-compulsive or superstitious behavior, I
suggest you do it using deposits of $5 to my PayPal account. First, you
deposit $5, then you do it again because you weren't really sure that you
did it the first time, then do it one more time, etc. ...

Setting free()'d pointers to NULL does not make the world a better or a
safer place.

The single exception is if you are using NULL as a sentinel value (perhaps
to indicate the the pointer is unused). But if you are NULL'ing pointers
just as a rote rule ... there isn't a lot of value there.

 

[Alef.Veld]

<[email protected]> wrote in message

<snip>

Personally i only use temporary locally scoped pointers anyway. So i
don't have this problem to begin with.

 

[Richard Bos]

What is wrong with #define myfree(p) {free(p),p=NULL; }

It gives you a warm, safe glow in your belly, which makes it harder for
you to pay attention to real danger.

Richard

 

[Clark S. Cox III]

<snip>

Personally i only use temporary locally scoped pointers anyway. So i
don't have this problem to begin with.

Then implementing a linked list must be a pain.

 

[Alef.Veld]

Then implementing a linked list must be a pain.

With the exception of linked lists that is
i still need to do that once actually, would make for a nice
excercise.

 

[Richard]

Hi,

What is wrong with #define myfree(p) {free(p),p=NULL; }

Instead of free , i ask my users to always call myfree. Are there any
limitations with that .


Does it have any speed overhead because of assignment.

Yes. But do do it. In the real world, when people are stepping through
system to find bugs using a debugger it is a LOT easier to spot bugs if
you dont have the mental over head of worrying about whether a pointer's
value is valid or not. There will be those who disagree. However, I have
never worked with someone on real systems with large code bases who
disagree though. It simply makes sense unless it is a very localised
pointer which is then re-assigned to in the same visible context.

 

[Richard Bos]

Yes. But do do it. In the real world, when people are stepping through
system to find bugs using a debugger it is a LOT easier to spot bugs if
you dont have the mental over head of worrying about whether a pointer's
value is valid or not.

So why use a hack which purports to let you do this, but instead lures
you into a false sense of security? Properly written code lets you
assume that a pointer is always good without using such tricks.

Richard