free question

[Roopa]

Hi,

There was some discussion here on checking for NULL before calling
'free'like
if (ptr != NULL)
free (ptr);

The person accused went on to say that this piece of code can work in
POSIX/QNX (libc library) and/also in someother environment. So, which
"free" you end up calling cannot be ascertained, hence i have checked
for NULL.

Now, my views would be since C89/C99 say free is NULL-safe so why
bother about the underlying environment. Am I correct here, or
should we bother to check the documentation/API ref manual of the
underlying OS and then code accordingly.

Thanks,
Roopa

 

[E. Robert Tisdale]

There was some discussion here on checking for NULL before calling
'free'like
if (ptr != NULL)
free (ptr);

The person accused went on to say that this piece of code can work in
POSIX/QNX (libc library) and/also in someother environment. So, which
"free" you end up calling cannot be ascertained, hence i have checked
for NULL.

Now, my views would be since C89/C99 say free is NULL-safe so why
bother about the underlying environment. Am I correct here, or
should we bother to check the documentation/API ref manual of the
underlying OS and then code accordingly.

Unfortunately, this is always the situation.
Complying with standards does *not* guarantee portable code.
If some of your target platforms don't support C99,
you may be obliged to restrict yourself to C90
or at least some subset of C99.
You should encourage your customers (employers)
to upgrade to the latest version of the standard of course
and it may help to refuse to support obsolete compilers.
You might also want to try something like this:

void my_free(void* ptr) {
if (NULL != prt)
free(ptr);
}

#define free(ptr) my_free(ptr)

 

[Dave Vandervies]

Hi,

There was some discussion here on checking for NULL before calling
'free'like
if (ptr != NULL)
free (ptr);

The person accused went on to say that this piece of code can work in
POSIX/QNX (libc library) and/also in someother environment. So, which
"free" you end up calling cannot be ascertained, hence i have checked
for NULL.

Now, my views would be since C89/C99 say free is NULL-safe so why
bother about the underlying environment. Am I correct here, or
should we bother to check the documentation/API ref manual of the
underlying OS and then code accordingly.

If it claims to be a C compiler, then don't worry about giving null
pointers to free(). If this leads to problems, it's a bug in the
implementation, so report it to the implementor as one.

If the underlying environment has problems with doing whatever it is
that free does with the pointer you give it with null pointers, it's the
responsibility of the library implementor to check that the pointer is
non-null before it does things that could cause problems.


There are things that you should check the underlying implementation's
handling of, but behavior guaranteed by the language you're working with
isn't among them.


dave

 

[Paul L Daniels]

POSIX/QNX (libc library) and/also in someother environment. So, which
"free" you end up calling cannot be ascertained, hence i have checked
for NULL.

I believe that may have been in part of my thread (C of Peril).

My view is that if you're attempting to free a NULL pointer when you're
assuming it should be non-NULL (by the program design) then you have an
issue somewhere (perhaps someone failed to check if malloc returned a
valid block).

Also yes, sometimes it's prudent to check the behaviour of freeing a
NULL prior to assuming it'll work on a particular platform.

PLD.

 

[Ravi Uday]

Unfortunately, this is always the situation.
Complying with standards does *not* guarantee portable code.
If some of your target platforms don't support C99,
you may be obliged to restrict yourself to C90
or at least some subset of C99.
You should encourage your customers (employers)
to upgrade to the latest version of the standard of course
and it may help to refuse to support obsolete compilers.
You might also want to try something like this:

void my_free(void* ptr) {
if (NULL != prt)
free(ptr);
}

#define free(ptr) my_free(ptr)

I dont think redefining free is a good way (there was a thread on
this type of redefining standard lib fns. sometime back from me)

 

[Ravi Uday]

I believe that may have been in part of my thread (C of Peril).

My view is that if you're attempting to free a NULL pointer when you're
assuming it should be non-NULL (by the program design) then you have an
issue somewhere (perhaps someone failed to check if malloc returned a
valid block).

Why would anyone want to free a NULL pointer !!!!!!!!!

Also yes, sometimes it's prudent to check the behaviour of freeing a
NULL prior to assuming it'll work on a particular platform.

Means, we need to check as a general case *all* the std. lib fns.
behaviour before we actually start using them. That would make you go
bonkers *@#$%^&**

I mean is there a rule or school of thought where one can go about
verifying some of the 'hot' std. functions (*alloc/free/*print*) with
that provided by the underlying implementation before one actually uses
them?

 

[Paul L Daniels]

Why would anyone want to free a NULL pointer !!!!!!!!!

Laziness? Poor/broken design? It's not that they'd explicitly want to
free a NULL pointer but rather that by allowing a NULL pointer to be
passed to free() (without segfaulting) you can get away with some
less-than-perfect program designs.

I'm sure there are other reasons, I just haven't as yet come up with a
good reason (for myself) to want to.

Paul.

 

[Richard Bos]

Laziness? Poor/broken design? It's not that they'd explicitly want to
free a NULL pointer but rather that by allowing a NULL pointer to be
passed to free() (without segfaulting) you can get away with some
less-than-perfect program designs.

It doesn't even need to be less-than-perfect. Consider, for example,
code which dynamically allocates space for a string. A pointer is
initialised to null, and a variable is created holding the size of the
allocated area in bytes; this is initialised to 0. Now whenever that
string needs to be larger than the current size, realloc() is used, and
if succesful, the new size is remembered. At the end of the program,
free() is called on the final pointer. Note that the first time
realloc() is called, it gets a null pointer argument; this is perfectly
alright, and acts as malloc(). All this is perfectly conforming. Now
consider a run through the program where this particular string is never
needed.

Richard

 

[Paul L Daniels]

free() is called on the final pointer. Note that the first time
realloc() is called, it gets a null pointer argument; this is perfectly
alright, and acts as malloc(). All this is perfectly conforming. Now
consider a run through the program where this particular string is never
needed.

The merits of the design of the program that requires this behaviour
could be debated though you would find that the two sides of the
argument will tend to be split along the separation between
theoretically correct and practical use.

A lot of the debate comes down to "Are you expecting a NULL when you go to
free". In the case you have provided, it would be already by design that
you're expecting a possible NULL and that is within your operational
specifications. The problem arises when a NULL is not anticipated (imo).

Paul

 

[Lawrence Kirby]

On Thu, 09 Dec 2004 20:50:17 -0800, E. Robert Tisdale wrote:

....

You might also want to try something like this:

Or even better don't, until you actually come across an implementation you
have to use that doesn't implement free() correctly.

void my_free(void* ptr) {
if (NULL != prt)
free(ptr);
}

#define free(ptr) my_free(ptr)

The C standard has required free() to behave (i.e. do nothing) for a null
pointer argument since 1989. If you are not prepared to rely on something
as basic and well established as this how many thousand other C language
features are you not prepared to rely on? Is there any part of the
language at all you feel can be used portably? Maybe your "fix" above
blows up because your compiler doesn't support void. The undefined
behaviour resulting from defining the reserved identifier free() means
that no C compiler is required to do what you want here.

Lawrence

 

[CBFalconer]

.... snip ...

You might also want to try something like this:

void my_free(void* ptr) {
if (NULL != prt)
free(ptr);
}

#define free(ptr) my_free(ptr)

As is normal with ERT, this is bad advice. Such redefinition of
free is expressly forbidden by the C standard, and results in
undefined behavior.

ERT (alias Trollsdale) has been told this multiple times, and that
quite recently. However he persists in spouting this faulty
method, and is apparently incapable of learning. If he is
afflicted with Parkinsons he might mention it, and we could be less
disdainful. If he is suffering from ADD I believe there are now
pills for that.

 

[Dave Vandervies]

As is normal with ERT, this is bad advice. Such redefinition of
free is expressly forbidden by the C standard, and results in
undefined behavior.

ERT (alias Trollsdale) has been told this multiple times, [...]
If he is suffering from ADD

Then he's doing something wrong; it should be enjoyed, not suffered.

But seriously, I doubt ADD would be a factor in this. Most ADDers I
know value accuracy more highly than normals tend to, and ERT has been
corrected on technical and conduct matters enough times that short-term
memory displacement is an inadequate explanation for his failure to
Get It.


dave
(stupidity and malice, perhaps? dangerous combination, that)

--
Dave Vandervies (e-mail address removed)

If you're going to flame somebody, get it right.

He did.
--Chris Dollin roasts a troll in comp.lang.c

 

[Herbert Rosenau]

Unfortunately, this is always the situation.
Complying with standards does *not* guarantee portable code.
If some of your target platforms don't support C99,
you may be obliged to restrict yourself to C90
or at least some subset of C99.
You should encourage your customers (employers)
to upgrade to the latest version of the standard of course
and it may help to refuse to support obsolete compilers.
You might also want to try something like this:

void my_free(void* ptr) {
if (NULL != prt)
free(ptr);
}

#define free(ptr) my_free(ptr)

Twitsdale is known as ignoring all and anything except the false noice
in his crappy brain. Irgnore anything he craps around.

free() IS NULL save - always.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

Laziness? Poor/broken design? It's not that they'd explicitly want to
free a NULL pointer but rather that by allowing a NULL pointer to be
passed to free() (without segfaulting) you can get away with some
less-than-perfect program designs.

I'm sure there are other reasons, I just haven't as yet come up with a
good reason (for myself) to want to.

Paul.

For that free(NULL) is guaranteed by the standards (even by the 15
years old one) to be save.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Keith Thompson]

There was some discussion here on checking for NULL before calling
'free'like
if (ptr != NULL)
free (ptr);
[...]

Now, my views would be since C89/C99 say free is NULL-safe so why
bother about the underlying environment. Am I correct here, or
should we bother to check the documentation/API ref manual of the
underlying OS and then code accordingly.

In my opinion, you're correct; implementations of free() that don't
handle null pointers properly are rare enough that probably it's not
worth the time to worry about them.

free(NULL) is a no-op, and is basically a waste of time. If your
program design has you freeing null pointers, you might consider
cleaning it up a bit, but I wouldn't make it a high priority. If your
program occasionally frees null pointers *accidentally* rather than by
design, that's a bug (and you'd be better off if free(NULL) aborted
rather than doing nothing).

Having said that, until it died a while ago I had a Sparcstation 2
running SunOS 4.1.3. I had installed gcc on it, so I had a
(basically) C90-compliant compiler, but it still used the old SunOS
runtime. I *think* it misbehaved on free(NULL). For some purposes,
such systems might be worth worrying about.

 

[Herbert Rosenau]

There was some discussion here on checking for NULL before calling
'free'like
if (ptr != NULL)
free (ptr);
[...]

Now, my views would be since C89/C99 say free is NULL-safe so why
bother about the underlying environment. Am I correct here, or
should we bother to check the documentation/API ref manual of the
underlying OS and then code accordingly.

In my opinion, you're correct; implementations of free() that don't
handle null pointers properly are rare enough that probably it's not
worth the time to worry about them.

free(NULL) is a no-op, and is basically a waste of time. If your
program design has you freeing null pointers, you might consider
cleaning it up a bit, but I wouldn't make it a high priority. If your
program occasionally frees null pointers *accidentally* rather than by
design, that's a bug (and you'd be better off if free(NULL) aborted
rather than doing nothing).

I'm trained well in writing functions who are tolerant to errors.
A NULL pointer will be dedected and handled but anyway as a function
is

1. initialision
can produce NULL pointers
will break down to cleanup the function when NULL pointer is
critical
2. do work
when needed with respect to NULL pointer(s) in detail
3. cleanup. No matter if work was done or not

results in free(NULL) often because a test for is superflous. Makes
the flow more clear.

Having said that, until it died a while ago I had a Sparcstation 2
running SunOS 4.1.3. I had installed gcc on it, so I had a
(basically) C90-compliant compiler, but it still used the old SunOS
runtime. I *think* it misbehaved on free(NULL). For some purposes,
such systems might be worth worrying about.

I've never seen such runtime since more than 16 years. Maybe there are
some pre-ANSI compilers exist who use a runtime where free (NULL) was
an error. But I've never seen such even in that time.

At least the standard is nothing more than a collection of practical
behavior of compilers, unifying them. So commonly used extensions
today will be found in the standard tomorrow. But free(NULL) is even
pre-ANSI practise, so it founds its place in the very first one.

You should know that Twitsdale is propagating "ignore the standard
because its useless" as he is using only one OS and one compiler on it
and had never the need to use another one. The normal developer will
be happy to be trained in the standard because he comes here with open
mind and knowth about the worth writing his code so compatible as
possible.

Even in an application that is designed to be properitary on an
specific OS and compiler there is enough that can be written easy to
be compatible to any OS and compiler on the world. Time changes, OSes
changes, compilers changes. And at that point you're happy about each
finction that is designed to be compatible because you've nothing more
to do than to recompile.

Rewiting things needed to be properiatry is hard enough, having
anything possible compatible to the standard makes porting more easy.
I had to work on a port from one properitary application system to
another OS - and was happy that it was designed to be portable so far
as possible. About 1 million lines of code - and 60% of them written
to be standard compilant.

No chance for the other 40% in any way as this was needed to use
properitary APIs because of performance. But the designers were awake
of the possibility to expand the user base to other OSes and had
encapsulated that.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!