gethostbyname() ---- Delete Resulting Pointer?

[CBFalconer]

As usual, you guys are no help, just sticklers for details.

Thanks for the non-help.

Congratulations. Your second post attained PLONK status. A new
record here.

PLONK

 

[Gordon Burditt]

I have the following snippet of code. On some platforms, the delete

calls works, on Linux, it core dumps (memory dump) at the delete
call. Am I responsible for deleting the memory that gethostbyname
allocated?

C does not have "new" or "delete".

*ANY* function that returns a pointer should include in its
documentation something to address this issue. Various possibilities
include (assuming the function doesn't return NULL):

(a) The pointer points into data that was passed in (e.g. strchr(),
strrchr(), etc.) You *MUST NOT* pass this pointer to free() since
the pointer may not be at the beginning of an allocated buffer,
even if it was allocated with malloc().

(a1) The pointer is a copy of a pointer passed in (e.g. fgets()).
If the original pointer was obtained from malloc(), you should
pass it to free() *once*, meaning you free either the pointer
passed in or the pointer returned, but *not* both.

(b) The pointer points into static (or maybe global) data that must
be copied before calling the function again if the value is
still needed. (e.g. localtime()) You *MUST NOT* pass this
pointer to free() since it was not malloc()ed in the first
place.

(b1) Some systems return pointers into "thread-specific storage",
and you should copy the data before calling the function again
if the value is still needed. You *MUST NOT* pass this pointer
to free() since it was not malloc()ed in the first place. The
only difference between this case and (b) is that in (b), the
function can't be thread-safe, and in this one, it might be.

(c) The function has an associated function to dispose of the pointer
returned. To avoid memory leaks, you should use this function
when you are through with the data. (e.g. fopen() returns a
pointer which should be passed to fclose()). Since there may
be more than one block of memory involved, and the pointer might
not point at the beginning of a block, you should use the
("destructor") function rather than calling free() to avoid
leaking memory or other resources.

(d) The function returns a pointer allocated by malloc(). When you
are through with the result, you should pass the pointer to
free(). (malloc() itself is an example of this. There's also
the infamous non-standard function strdup().) Functions like
this are the C analogy to C++ "constructors" where a simple
call to free() is adequate as a "destructor".

(e) The function returns a pointer allocated by malloc(), but it
still is keeping track of it. You should not pass this pointer
to free() since the data is still in use. (Some in-memory database
functions return pointers to retrieved records but you shouldn't
free() the records until you close the whole database, and the
close function is probably responsible for that.)

(f) The function returns a pointer that may or may not be allocated
with malloc(), points to static data, or points into data passed
into the function, with no obvious way to tell which. You can't
risk calling free() on the resulting pointer, and you should
fire the guy who writes code like this.

I am under the impression that you don't delete anything unless you
personally "new'ed" it. Is this theory correct in this situation?

You don't free() anything if it was not malloc()ed or it is still
in use. "personally" doesn't enter into it. It is common for a
function (C's analogy to a "constructor") to return a pointer to
data which the caller is responsible for dealing with (see cases
(c) and (d)) by calling either free() or a "destructor" function.
A function like this needs to be documented.

<off-topic>
On one particular system, gethostbyname() comes under (b1) above,
and on others it is either in (b) or (b1). Don't free the pointer
it returns.
</off-topic>

 

[SM Ryan]

# I have the following snippet of code. On some platforms, the delete
# calls works, on Linux, it core dumps (memory dump) at the delete
# call. Am I responsible for deleting the memory that gethostbyname
# allocated?

What does the documentation say?

 

[Joachim Schmitz]

My question wasn't about "delete" or "new". My question was if I am
responsible for deallocating the pointer provided by a certain
function.

And the answer to that is implementation/function specific, your
documentation should tell you about it. As it wasn't a Standard C function,
we can't really tell here
On one system I work on gethostbyname() is documented to return a value that
points to static data, so calling free() (or delete) won't work.

I wasn't aware that that particular function,
gethostbyname(), isn't in the C standard. Regardless, it is still C
syntax, compiled by a C compiler. I will save future (read: all)
questions for a more appropriate newsgroup. Sorry you felt the need
to plonk me.

I didn't (still the proud owner of an entirely empty killfile), but others
might, just due to the tone of your reply to the help you've been given.

Bye, Jojo

 

[Kenneth Brody]

Acknowledged. Except you guys aren't stockboys. Stockboys don't know
what to do about the flu. You hardened C types, however, have the
knowledge to provide insight into my dilemna, so I dismiss your
analogy !

Perhaps this wording is better?

One would infer that when you have a strange growth on your arm,
you go to your local medical building and ask a pediatrician what
to do about it, and are offended when he suggests you ask a
dermatologist or oncologist. ("You guys are no help, just
sticklers for details.")

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Thad Smith]

Am I responsible for deleting the memory that gethostbyname
allocated?

*ANY* function that returns a pointer should include in its
documentation something to address this issue. Various possibilities
include (assuming the function doesn't return NULL):

(a) The pointer points into data that was passed in (e.g. strchr(),
> ... [several other categories of returned pointers]
(f) The function returns a pointer that may or may not be allocated
with malloc(), points to static data, or points into data passed
into the function, with no obvious way to tell which. You can't
risk calling free() on the resulting pointer, and you should
fire the guy who writes code like this.

Thanks for the excellent response, Gordon.

 

[Paul Sinnett]

What does the documentation say?

It says you don't delete the memory. It also says the returned
structure may be overwritten by subsequent calls. And if you want to
make a copy it should be a deep copy because it contains pointers to
other static memory.