Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > When it will be freed?

Reply
Thread Tools

When it will be freed?

 
 
tfelb
Guest
Posts: n/a
 
      01-20-2009
Hi group!

There are many string functions out there and many use malloc/calloc
mechanisms /but/ they aren't freed before the function returns? When
it will be freed? Because if I use strdup many times the function
malloc's every time more space from the heap or is my thesis wrong?

I saw many implementations of strdup and they all are similar

char *strdup(char *s1)
{

char *newString;
newString = (char *)malloc(strlen(s1) + 1); /* I know casting
malloc isn't necessary
strcpy(newString,s1);
return newString; /* no freeing */
}

Thank you!

Tom F.



 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-20-2009
tfelb <(E-Mail Removed)> writes:

> There are many string functions out there and many use malloc/calloc
> mechanisms /but/ they aren't freed before the function returns? When
> it will be freed? Because if I use strdup many times the function
> malloc's every time more space from the heap or is my thesis wrong?


That's right. The program using the function need to free the
space when it know there is not more use for it. Only the programmer
knows when this is.

> I saw many implementations of strdup and they all are similar
>
> char *strdup(char *s1)
> {
>
> char *newString;
> newString = (char *)malloc(strlen(s1) + 1); /* I know casting
> malloc isn't necessary
> strcpy(newString,s1);
> return newString; /* no freeing */
> }


const char * would be a better type for the parameter and something
other then undefined behaviour should happen when malloc returns NULL.

--
Ben.
 
Reply With Quote
 
 
 
 
Rafael
Guest
Posts: n/a
 
      01-20-2009
tfelb escreveu:
> Hi group!
>
> There are many string functions out there and many use malloc/calloc
> mechanisms /but/ they aren't freed before the function returns? When
> it will be freed? Because if I use strdup many times the function
> malloc's every time more space from the heap or is my thesis wrong?
>
> I saw many implementations of strdup and they all are similar
>
> char *strdup(char *s1)
> {
>
> char *newString;
> newString = (char *)malloc(strlen(s1) + 1); /* I know casting
> malloc isn't necessary
> strcpy(newString,s1);
> return newString; /* no freeing */
> }


Memory free'd on caller side, maybe? You are receiving a pointer to
char... you can just do

char *whatever = strdup(whatothereverchar);

if(whatever)
free(whatever);


Rafael
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      01-20-2009
tfelb <(E-Mail Removed)> writes:

> Hi group!
>
> There are many string functions out there and many use malloc/calloc
> mechanisms /but/ they aren't freed before the function returns? When
> it will be freed? Because if I use strdup many times the function
> malloc's every time more space from the heap or is my thesis wrong?


It is your responsible to free them.

>
> I saw many implementations of strdup and they all are similar
>
> char *strdup(char *s1)
> {
>
> char *newString;
> newString = (char *)malloc(strlen(s1) + 1); /* I know casting
> malloc isn't necessary


And is bad. Apparently but I never saw any side affects. The "danger" is
a c.l.c thing but why tempt fate? Remove the cast.

> strcpy(newString,s1);
> return newString; /* no freeing */
> }



Something (untested) like this is fine IMO.

char * strdup(char *s){
return strcpy(malloc(strlen(s)+1),s);
}

Perfect. Nice crash if you run out of malloc space too. But if you do
then the system is hosed anyway.....

 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      01-20-2009
Rafael wrote:
> tfelb escreveu:
>> Hi group!
>>
>> There are many string functions out there and many use malloc/calloc
>> mechanisms /but/ they aren't freed before the function returns? When
>> it will be freed? Because if I use strdup many times the function
>> malloc's every time more space from the heap or is my thesis wrong?
>>
>> I saw many implementations of strdup and they all are similar
>>
>> char *strdup(char *s1)
>> {
>>
>> char *newString;
>> newString = (char *)malloc(strlen(s1) + 1); /* I know casting
>> malloc isn't necessary
>> strcpy(newString,s1);
>> return newString; /* no freeing */
>> }

>
> Memory free'd on caller side, maybe? You are receiving a pointer to
> char... you can just do
>
> char *whatever = strdup(whatothereverchar);
>
> if(whatever)
> free(whatever);


As free(NULL); is perfectly legal (and a NOP), you can even drop the if
(whatever) and save the cycles

Bye, Jojo

 
Reply With Quote
 
David Resnick
Guest
Posts: n/a
 
      01-20-2009
On Jan 20, 10:44*am, tfelb <(E-Mail Removed)> wrote:
> There are many string functions out there and many use malloc/

calloc
> mechanisms /but/ they aren't freed before the function returns? When
> it will be freed? Because if I use strdup many times the function
> malloc's every time more space from the heap or is my thesis wrong?
>
> I saw many implementations of strdup and they all are similar
>
> char *strdup(char *s1)
> {
>
> * *char *newString;
> * *newString = (char *)malloc(strlen(s1) + 1); /* I know casting
> malloc isn't necessary
> * *strcpy(newString,s1);
> * *return newString; */* no freeing */
>
> }


strdup is non-standard but widely used. Accessing your system
documentation will probably tell you something like this seen on
linux:

The strdup() function returns a pointer to a new string which
is a duplicate of the string s. Memory for the new string is obtained
with malloc(3), and can be freed with free(3).

i.e. when you are done with the string returned, you should call free
on the returned pointer or you will leak memory.

The above is a subpar implementation of strdup for a number of reasons
not relevant to your question, btw. Some things that might be done
differently:

1) name is in implementation namespace (strx), but whatever, it is a
very common
extension, I expect any future standard function named "strdup"
would have
identical signature and semantics to the widely available one.
So no big
problem presumably.
2) Argument should really be const char*.
3) Doesn't check argument for NULL
4) Doesn't check malloc for success (at least on my system is
documented to set
errno to ENOMEM on malloc failure)
5) Casts malloc (which you noted, discussed to death, so whatever)
6) I'd rather use memcpy (since the strlen is already measured once in
fn)

Some of the above are just design decisions I guess...

-David



 
Reply With Quote
 
tfelb
Guest
Posts: n/a
 
      01-20-2009
On 20 Jan., 17:12, David Resnick <(E-Mail Removed)> wrote:
> On Jan 20, 10:44*am, tfelb <(E-Mail Removed)> wrote:
> *> There are many string functions out there and many use malloc/
> calloc
>
>
>
>
>
> > mechanisms /but/ they aren't freed before the function returns? When
> > it will be freed? Because if I use strdup many times the function
> > malloc's every time more space from the heap or is my thesis wrong?

>
> > I saw many implementations of strdup and they all are similar

>
> > char *strdup(char *s1)
> > {

>
> > * *char *newString;
> > * *newString = (char *)malloc(strlen(s1) + 1); /* I know casting
> > malloc isn't necessary
> > * *strcpy(newString,s1);
> > * *return newString; */* no freeing */

>
> > }

>
> strdup is non-standard but widely used. *Accessing your system
> documentation will probably tell you something like this seen on
> linux:
>
> * * * *The strdup() function returns a pointer to a new string which
> is a duplicate of the string s. *Memory for the new string is obtained
> with malloc(3), and can *be *freed with free(3).
>
> i.e. when you are done with the string returned, you should call free
> on the returned pointer or you will leak memory.
>
> The above is a subpar implementation of strdup for a number of reasons
> not relevant to your question, btw. *Some things that might be done
> differently:
>
> 1) name is in implementation namespace (strx), but whatever, it is a
> very common
> * * * extension, I expect any future standard function named "strdup"
> would have
> * * * identical signature and semantics to the widely available one..
> So no big
> * * * problem presumably.
> 2) Argument should really be const char*.
> 3) Doesn't check argument for NULL
> 4) Doesn't check malloc for success (at least on my system is
> documented to set
> * * * * *errno to ENOMEM on malloc failure)
> 5) Casts malloc (which you noted, discussed to death, so whatever)
> 6) I'd rather use memcpy (since the strlen is already measured once in
> fn)
>
> Some of the above are just design decisions I guess...
>
> -David- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


Thank you! This was a test function with no built-in checks.
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      01-20-2009
Gordon Burditt wrote:
>> Because if I use strdup many times the function
>> malloc's every time more space from the heap or is my thesis wrong?

>
> strdup() (not a standard C function) wouldn't be very useful if it
> kept re-using the same memory to store strings.


Exactly. One of the common uses for strdup() is to "fix" functions that
return a pointer to a static buffer, so if strdup() did the same thing,
it'd be rather pointless.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Isaac Jaffe
 
Reply With Quote
 
Rafael
Guest
Posts: n/a
 
      01-20-2009
Joachim Schmitz escreveu:

> As free(NULL); is perfectly legal (and a NOP), you can even drop the if
> (whatever) and save the cycles


Wouldn't I save a cycle not calling free?

Rafael
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      01-20-2009
In article <gl4uc0$rub$(E-Mail Removed)>,
Rafael <(E-Mail Removed)> wrote:

>> As free(NULL); is perfectly legal (and a NOP), you can even drop the if
>> (whatever) and save the cycles


>Wouldn't I save a cycle not calling free?


Several, but only when strdup() failed, which Is hardly ever going to
be true.

Either way, the difference is unlikely to be noticable.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments