about MALLOC

[Caroline]

What is MALLOC exactly?
Where is it used?
Can someone please provide me with descriptive examples?

Thank you

[Joona I Palaste]

Caroline <pl***@letsdothatagain.com> scribbled the following:

What is MALLOC exactly?
We don't know. malloc, OTOH, is a C function.
Where is it used?
Wherever you need to dynamically allocate memory.
Can someone please provide me with descriptive examples?

char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo);

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Insanity is to be shared."
- Tailgunner

[Eric]

Caroline <pl***@letsdothatagain.com> wrote:

What is MALLOC exactly?
A function to allocate memory dynamically
Where is it used?
When you cannot or do not want to allocate memory statically
Can someone please provide me with descriptive examples?

<http://www.google.com/search?q=mallo...zilla-search&s
tart=0&start=0&ie=utf-8&oe=utf-8>

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

[Robert Stankowic]

"Caroline" <pl***@letsdothatagain.com> schrieb im Newsbeitrag
news:da**************************@posting.google.c om...

What is MALLOC exactly?
Where is it used?
Can someone please provide me with descriptive examples?

Joona's example
(hope, you don't mind, Joona)

char *foo = malloc(6);
You request memory, enough for 6 characters..

if (foo)
If the request is granted, foo contains nof the address of the first
character of those six

strcpy(foo, "Hello");
Now you copy the characters 'H', 'e', 'l', 'l', 'o', and 0
into that memory space,
do your stuff with these characters...

free(foo);
As soon as you are done, you give that memory back.

[Jake Roersma]

On Tue, 09 Dec 2003 20:50:29 +0100, Robert Stankowic wrote:

Joona's example
(hope, you don't mind, Joona)

strcpy(foo, "Hello");
Now you copy the characters 'H', 'e', 'l', 'l', 'o', and 0

It should be the characters 'H', 'e', 'l', 'l', 'o' and '\0'

- Jake

[Arthur J. O'Dwyer]

On Tue, 9 Dec 2003, Jake Roersma wrote:

On Tue, 09 Dec 2003 20:50:29 +0100, Robert Stankowic wrote:

Joona's example
(hope, you don't mind, Joona)

strcpy(foo, "Hello");
Now you copy the characters 'H', 'e', 'l', 'l', 'o', and 0

It should be the characters 'H', 'e', 'l', 'l', 'o' and '\0'

'\0' and 0 are synonyms in C.

assert('\0' == 0);

I think this is true in all possible contexts in which 0 or '\0'
could be a complete token, but I would welcome counter-examples
if any exist.

-Arthur

[Joona I Palaste]

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> scribbled the following:

On Tue, 9 Dec 2003, Jake Roersma wrote:

On Tue, 09 Dec 2003 20:50:29 +0100, Robert Stankowic wrote:

> Joona's example
> (hope, you don't mind, Joona)
>
> strcpy(foo, "Hello");
> Now you copy the characters 'H', 'e', 'l', 'l', 'o', and 0
It should be the characters 'H', 'e', 'l', 'l', 'o' and '\0'

'\0' and 0 are synonyms in C. assert('\0' == 0); I think this is true in all possible contexts in which 0 or '\0'
could be a complete token, but I would welcome counter-examples
if any exist.

Well, if 0 has not been defined... erm, wait a moment...
Seeing as neither '\0' or 0 has any alphabetic characters,
underscores or dollar signs, I think it's safe to say that the only
place one of them would not stand in for the other would be in a
comment or in a string literal.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Holy Banana of this, Sacred Coconut of that, Magic Axolotl of the other."
- Guardian in "Jinxter"

[Malcolm]

"Caroline" <pl***@letsdothatagain.com> wrote in message

What is MALLOC exactly?
Where is it used?
Can someone please provide me with descriptive examples?

The standard libray function is malloc(), not capitalised.

Imagine you are writing a payroll program. You have some employees

typedef struct
{
char name[128];
float salary;
} EMPLOYEE;

If you have ten employees you could declare an array

EMPLOYEE myemployees[10];

However in a real company you probably don't know how many employees you
will have. You might expand or contract dramatically.

To solve the problem, we do this.

EMPLOYEE *myemployees;

myemployees = malloc(N * sizeof(EMPLOYEE));

N is input from the user or read from a file, at run time. As long as the
computer has enough memory, you can effectively have an array of any number
of employees.

malloc() is at the heart of C programming. If you want to program in C, you
must learn to use it.

[Dan Pop]

In <da**************************@posting.google.com > pl***@letsdothatagain.com (Caroline) writes:

What is MALLOC exactly?
Where is it used?
Can someone please provide me with descriptive examples?

This newsgroup is not supposed to be used as a substitute for reading
a C book.

Any good C tutorial book provides better explanations and more
descriptive examples than you can hope to get here.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alexandre Jasmin]

>> Can someone please provide me with descriptive examples?

char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo);

char *foo = malloc(6);
if (foo) {
strcpy(foo, "Hello");
free(foo);
}

[Joona I Palaste]

Alexandre Jasmin <al*********@sympatico.ca> scribbled the following:

Can someone please provide me with descriptive examples? char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo);

char *foo = malloc(6);
if (foo) {
strcpy(foo, "Hello");
free(foo);
}

Um, free(foo); is safe even if "if (foo)" fails, because then foo will
be NULL, and free(NULL) is a safe no-op.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates

[Alex]

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Alexandre Jasmin <al*********@sympatico.ca> scribbled the following:

Can someone please provide me with descriptive examples?
char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo);

char *foo = malloc(6);
if (foo) {
strcpy(foo, "Hello");
free(foo);
}

Um, free(foo); is safe even if "if (foo)" fails, because then foo will
be NULL, and free(NULL) is a safe no-op.

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised. If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid. If nothing
else, this provides symmetry to 'fopen' and 'fclose'.

Alex

[Joona I Palaste]

Alex <al*******@hotmail.com> scribbled the following:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Alexandre Jasmin <al*********@sympatico.ca> scribbled the following:

> Can someone please provide me with descriptive examples?
char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo); char *foo = malloc(6);
if (foo) {
strcpy(foo, "Hello");
free(foo);
}

Um, free(foo); is safe even if "if (foo)" fails, because then foo will
be NULL, and free(NULL) is a safe no-op.

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised. If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid. If nothing
else, this provides symmetry to 'fopen' and 'fclose'.

There *is* something else - it saves a potential performance delay by
avoiding computing the address of free and jumping to that code, and
then immediately coming back from it. The compiler can, of course,
optimise "free(NULL);" to no code at all, but I don't think compilers
are sufficiently clever to remove the call to free() from the above
code, should the malloc() fail.
But still I chose to write the code the way I did, if nothing else, to
show that free(NULL) is valid.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To know me IS to love me."
- JIPsoft

[CBFalconer]

Alex wrote:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Alexandre Jasmin <al*********@sympatico.ca> scribbled the following:

char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo); char *foo = malloc(6);
if (foo) {
strcpy(foo, "Hello");
free(foo);
}

Um, free(foo); is safe even if "if (foo)" fails, because then
foo will be NULL, and free(NULL) is a safe no-op.

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised. If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid. If nothing
else, this provides symmetry to 'fopen' and 'fclose'.

So what? The first was an example, and perfectly correct. There
was no reason for the second version to be posted other than the
joy of creating useless clutter. Your reasoning remains valid,
but has no application to this thread. If Alexandre Jasmin had
wished to make your point he could have done so, instead of
posting unannotated corrections to correct code for no discernable
reason.

The post should have been simply ignored.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Alex]

CBFalconer <cb********@yahoo.com> wrote:

Alex wrote:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

> Alexandre Jasmin <al*********@sympatico.ca> scribbled the following:

>>> char *foo = malloc(6);
>>> if (foo)
>>> strcpy(foo, "Hello");
>>> free(foo);

>> char *foo = malloc(6);
>> if (foo) {
>> strcpy(foo, "Hello");
>> free(foo);
>> }

> Um, free(foo); is safe even if "if (foo)" fails, because then
> foo will be NULL, and free(NULL) is a safe no-op.

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised. If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid. If nothing
else, this provides symmetry to 'fopen' and 'fclose'.

So what? The first was an example, and perfectly correct. There
was no reason for the second version to be posted other than the
joy of creating useless clutter. Your reasoning remains valid,
but has no application to this thread. If Alexandre Jasmin had
wished to make your point he could have done so, instead of
posting unannotated corrections to correct code for no discernable
reason.

Fair enough.

Alex

[Mark McIntyre]

On 10 Dec 2003 18:40:28 GMT, in comp.lang.c , Alex
<al*******@hotmail.com> wrote:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Um, free(foo); is safe even if "if (foo)" fails, because then foo will
be NULL, and free(NULL) is a safe no-op.
Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised.

why not? If you are guaranteed that something is done, then you can
safely rely on it.
If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid.

All you're doing is adding overhead to the code. This might be
important in time-critical programming.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Bertrand Mollinier Toublet]

Joona I Palaste wrote:

char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo);

Then wrote:

The compiler can, of course,
optimise "free(NULL);" to no code at all, but I don't think compilers
are sufficiently clever to remove the call to free() from the above
code, should the malloc() fail.

In most cases, you write calls to malloc in the hope that they will
succeed. Thus, a malloc failure is an event that will only be determined
at run time. Thus, the compiler, which only does a static analysis of
your code will NOT EVER be able to remove "calls to free() should the
malloc() fail".

There is a conceptual difference between:

void *ptr = NULL;
free(ptr);

and

void *ptr = malloc(some_integer_value);
free(ptr);

--
Bertrand Mollinier Toublet
"Reality exists" - Richard Heathfield, 1 July 2003

[Bruno Desthuilliers]

Eric wrote:

Caroline <pl***@letsdothatagain.com> wrote:

What is MALLOC exactly?

A function to allocate memory dynamically

I didn't find any function named "MALLOC" in my implementation (gcc...).
There is a "malloc" function, but since C is case-sensitive, it cannot
be the same !-)

Bruno

[Joona I Palaste]

Bruno Desthuilliers <bd***********@removeme.free.fr> scribbled the following:

Eric wrote:

Caroline <pl***@letsdothatagain.com> wrote:

What is MALLOC exactly?
A function to allocate memory dynamically

I didn't find any function named "MALLOC" in my implementation (gcc...).
There is a "malloc" function, but since C is case-sensitive, it cannot
be the same !-)

I got to thinking... why are we all so smugly saying *both* "It's
malloc. not MALLOC" *and* "Read your friendly textbook" to Caroline?
What if she *knows* what malloc is, but has *really* encountered
*MALLOC* and doesn't know what it is? (Anymore than we do, because
it's not standard C.)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To err is human. To really louse things up takes a computer."
- Anon

[Grumble]

Mark McIntyre wrote:

Alex wrote:

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised.

why not? If you are guaranteed that something is done, then you can
safely rely on it.

If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid.

All you're doing is adding overhead to the code. This might be
important in time-critical programming.

Overhead? Could you, please, elaborate?

Joona's code will call free() every time. Alexandre's code will call
free() every time - epsilon.

[nrk]

Grumble wrote:

Mark McIntyre wrote:

Alex wrote:

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised.

why not? If you are guaranteed that something is done, then you can
safely rely on it.

If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid.

All you're doing is adding overhead to the code. This might be
important in time-critical programming.

Overhead? Could you, please, elaborate?

Joona's code will call free() every time. Alexandre's code will call
free() every time - epsilon.

Joona's code will not check the pointer against NULL everytime. Alexandre's
code will. Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary check and
optimize the most common case.

-nrk.

[Grumble]

nrk wrote:

Grumble wrote:

Mark McIntyre wrote:

All you're doing is adding overhead to the code. This might be
important in time-critical programming.

Overhead? Could you, please, elaborate?

Joona's code will call free() every time. Alexandre's code will call
free() every time - epsilon.

Joona's code will not check the pointer against NULL everytime. Alexandre's
code will. Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary check and
optimize the most common case.

Someone snipped too much context.

Joona wrote:

char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo);

How can you say that Joona's code will not check the pointer's value?

This is not a free(p) vs if (p) free(p) issue. The test must be done.

[Joona I Palaste]

nrk <ra*********@deadbeef.verizon.net> scribbled the following:

Grumble wrote:

Mark McIntyre wrote:

Alex wrote:

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised.

why not? If you are guaranteed that something is done, then you can
safely rely on it.

If you
know whether your pointer is valid or not from the context, it
makes more sense to free it only if it is valid.

All you're doing is adding overhead to the code. This might be
important in time-critical programming.
Overhead? Could you, please, elaborate?

Joona's code will call free() every time. Alexandre's code will call
free() every time - epsilon.

Joona's code will not check the pointer against NULL everytime. Alexandre's
code will. Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary check and
optimize the most common case.

Grumble is right, my code *will* check against NULL every time. It is
also true that there is *more* overhead in my code than in Alexandre's.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller

[Dan Pop]

In <br**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Bruno Desthuilliers <bd***********@removeme.free.fr> scribbled the following:

Eric wrote:

Caroline <pl***@letsdothatagain.com> wrote:

What is MALLOC exactly?

A function to allocate memory dynamically

I didn't find any function named "MALLOC" in my implementation (gcc...).
There is a "malloc" function, but since C is case-sensitive, it cannot
be the same !-)

I got to thinking... why are we all so smugly saying *both* "It's
malloc. not MALLOC" *and* "Read your friendly textbook" to Caroline?
What if she *knows* what malloc is, but has *really* encountered
*MALLOC* and doesn't know what it is? (Anymore than we do, because
it's not standard C.)

In this case, she would have worded her question differently.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <3f***********************@news.free.fr> Bruno Desthuilliers <bd***********@removeme.free.fr> writes:

Eric wrote:

Caroline <pl***@letsdothatagain.com> wrote:

What is MALLOC exactly?

A function to allocate memory dynamically

I didn't find any function named "MALLOC" in my implementation (gcc...).
There is a "malloc" function, but since C is case-sensitive, it cannot
be the same !-)

When it comes to external identifiers, C89 is not necessarily case
sensitive ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Randy Howard]

In article <ol*****************@nwrddc01.gnilink.net>, ram_nrk2000
@deadbeef.verizon.net says...

Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary
check and optimize the most common case.

-nrk.

You've got to be kidding. malloc() can indeed fail, and often,
particularly in algorithms that increase the size of the malloc
call (or realloc) exponentially for large data structures. Consider
what happens when you try to make a > 2GB malloc() request on a 32-bit
system for a moment. I've seen it happen.

Further, not all OS's support VM in a way that you always get the
memory you need from a malloc call on a heavily loaded system, even
for smaller amounts.

You *really* shouldn't be believing, or dishing out this type of
advice.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com

[Robert Bachmann]

Caroline wrote:

What is MALLOC exactly?
Where is it used?
Can someone please provide me with descriptive examples?

http://www.rocketaware.com/man/man3/malloc.3.htm
possibly provides a good overview.

Regards,
Robert
--
Robert Bachmann - Ro*************@rbdev.net (pgp key available)

[Mark McIntyre]

On Thu, 11 Dec 2003 14:10:01 +0100, in comp.lang.c , Grumble
<in*****@kma.eu.org> wrote:

Mark McIntyre wrote:

All you're doing is adding overhead to the code. This might be
important in time-critical programming.

Overhead? Could you, please, elaborate?

Joona's code will call free() every time. Alexandre's code will call
free() every time - epsilon.

One of them performs an extra comparison.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

On Thu, 11 Dec 2003 14:42:14 +0100, in comp.lang.c , Grumble
<in*****@kma.eu.org> wrote:

Someone snipped too much context.
the context of my reply is this one:

On 10 Dec 2003 18:40:28 GMT, in comp.lang.c , Alex
<al*******@hotmail.com> wrote:Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised.
which I took to mean "just because free() gracefully handles NULL,
doesn't mean you should always rely on this funcitonality".
This is not a free(p) vs if (p) free(p) issue.
that certainly wasn't clear to me.
The test must be done.

in the case of actually using foo, yup.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[nrk]

Randy Howard wrote:

In article <ol*****************@nwrddc01.gnilink.net>, ram_nrk2000
@deadbeef.verizon.net says...

Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary
check and optimize the most common case.

-nrk.

You've got to be kidding. malloc() can indeed fail, and often,
particularly in algorithms that increase the size of the malloc
call (or realloc) exponentially for large data structures. Consider
what happens when you try to make a > 2GB malloc() request on a 32-bit
system for a moment. I've seen it happen.

Further, not all OS's support VM in a way that you always get the
memory you need from a malloc call on a heavily loaded system, even
for smaller amounts.

You *really* shouldn't be believing, or dishing out this type of
advice.

Sorry, my mistake (but not the one you think I made). Too much context was
snipped out, and like the idiot that I am I didn't refer upthread to
refresh the context... I was talking about checking the pointer just before
calling free as in:
if ( ptr ) free(ptr);
which as you know is quite wasteful. Of course, this wasn't what was being
done in the code in question. I am in total agreement with your opinion on
checking malloc's return value.

-nrk.

[Alex]

nrk <ra*********@deadbeef.verizon.net> wrote:

Randy Howard wrote:

In article <ol*****************@nwrddc01.gnilink.net>, ram_nrk2000
@deadbeef.verizon.net says...

Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary
check and optimize the most common case.

-nrk.

You've got to be kidding. malloc() can indeed fail, and often,
particularly in algorithms that increase the size of the malloc
call (or realloc) exponentially for large data structures. Consider
what happens when you try to make a > 2GB malloc() request on a 32-bit
system for a moment. I've seen it happen.

Further, not all OS's support VM in a way that you always get the
memory you need from a malloc call on a heavily loaded system, even
for smaller amounts.

You *really* shouldn't be believing, or dishing out this type of
advice.

Sorry, my mistake (but not the one you think I made). Too much context was
snipped out, and like the idiot that I am I didn't refer upthread to
refresh the context... I was talking about checking the pointer just before
calling free as in:
if ( ptr ) free(ptr);
which as you know is quite wasteful. Of course, this wasn't what was being

This is *never* necessary. It is arguably stylistically
better to free the pointer in the context in which it is
known to be valid, if such context is available. If it is
not, there is absolutely no need to introduce the check
specifically for 'free'.

Alex

[Randy Howard]

In article <1C****************@nwrddc02.gnilink.net>, ram_nrk2000
@deadbeef.verizon.net says...

Sorry, my mistake (but not the one you think I made). Too much context was
snipped out, and like the idiot that I am I didn't refer upthread to
refresh the context... I was talking about checking the pointer just before
calling free as in:
if ( ptr ) free(ptr);
which as you know is quite wasteful.

Sorry, I could have read more of the context as well.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com