Will it cause problems if I call free() on a char* that I never called malloc() for?
Printable View
Will it cause problems if I call free() on a char* that I never called malloc() for?
Probably. And what do you hope to achieve with that?
It was a timing issue I was worried about. There was a chance that the way I had structured my main loop, that I might be freeing a variable that might not have been malloced during the iteration.
I wondered if I'd need to set a flag to make sure.
Another way to check this is to set those variable to NULL when they are declared or freed:Quote:
Originally Posted by Bladactania
Pointers are never set to NULL (either when initialized or freed) unless you do it, but if they are NULL then you know who did it and why (hopefully: they are already freed or unallocated*). This is easier than using a flag.Code:char *ptr=NULL;
[various things may or may not happen]
if (ptr) { free(ptr); ptr=NULL; }
*remember that setting an allocated pointer to NULL does not free it, so would be a memory leak...
I seem to remember seeing somewhere that you cannot allocate memory for a pointer that is already set to NULL. Is this true?
Huh? If what you mean by this is:Quote:
Originally Posted by Bladactania
would be wrong, then you have misunderstood. This code-snippet is perfectly valid and correct.Code:int *ptr = NULL;
ptr = malloc(...);
--
Mats
Gotta concur with matsp, I do this all the time and so should you!Quote:
Originally Posted by Bladactania
Instead of NULL, would setting the prt to 0 work?
I guess; but that will become an obscurantist habit (because it is very normal to set a pointer to NULL for exactly these reasons).Quote:
Originally Posted by Bladactania
Why not just use NULL????
It is not as obscure as you think: 0 is a null pointer constant.Quote:
Originally Posted by MK27
Personal choice to avoid the use of a macro.Quote:
Originally Posted by MK27
NULL and 0 are essentially the same thing - serves the same purpose and behaves the same. Any particular reason you prefer to use 0?
--
Mats
NULL being the macro I guess. That's a decent reason.Quote:
Originally Posted by laserlight
And I suppose if I saw this:
I would immediately associate it with NULL, so not obscure at all. Sorry.Code:char *ptr=0;
But then if you have a long function with something like this:
That's why I use NULL. It makes is clear that the variable it's being assigned to is a pointer.Code:char* blah = 0; // You can clearly see it's a pointer since you see the declaration.
...
...
blah = 0; // Not so obvious 50 or more lines down since you can't see how blah is declared. Is it a pointer or an int?
And yes, since NULL is 0 you could assign NULL to an int, but that would just be dumb.
Although, usually the name of the variable itself gives you a pretty good idea about it's type since a lot of people prefix pointers with 'p'...
Hence a function should do one thing and do it well ;)Quote:
Originally Posted by cpjust
Unless a mistake is made for the same reason as you cite NULL being useful. The reader would then be misinformed unless he/she checked, but if he/she checked then the use of NULL would no longer be useful.Quote:
Originally Posted by cpjust
The closest I can say that's remotely connected to is reallocQuote:
Bladactania:
I seem to remember seeing somewhere that you cannot allocate memory for a pointer that is already set to NULL. Is this true
You can call realloc() on a NULL pointer.Quote:
Originally Posted by JVene
I agree, of course you can. You have to be able to allocate pointer for NULL pointers, because of the simple concept of the "initialize your variables before you attempt to use them" mantra.Quote:
Originally Posted by bithub
All a NULL pointer is is a variable whose value has been set to nothing. It's like initializing an int to 0 first.
Quzah.
6 in one, half a dozen in the other...Quote:
Originally Posted by laserlight
Both ways have advantages & disadvantages.
I would assume that if someone did find a discrepancy as you mentioned, they would fix it so the next reader doesn't have to go through the same head scratching motion. In 10 years I've never seen anyone try to assign NULL to a non-pointer. So I would say it's an extremely remote possibility.
That's right, which is why I think it boils down to personal choice. In C++ we can wait for nullptr, but I am afraid there is no good solution coming up for C.Quote:
Originally Posted by cpjust
I have done it myself when using some of those crazy programming interfaces with an excessive number of parameters, some of which are pointers while others are not. It is arguably a problem with the interface, but in such cases it does not matter whether the reader sees a NULL or a 0: he/she has to double check anyway.Quote:
Originally Posted by cpjust