free(); after return();?

[Robert]

Alright, here's my situation:

if i use malloc like:

char *mystring;

mystring = (char *)malloc(80);

return mystring;
free(mystring);

is the memory of mystring then freed or does this creates
memory leaks? And if so, how could i prevent this?

Thanks in advance,
Robert

 

[Greg P.]

| is the memory of mystring then freed or does this creates
| memory leaks? And if so, how could i prevent this?


it sure does, as free is not reached.

Outside of your function call free() on it once you are done with it. It
doesn't have to be in the same scope.

 

[ipo]

The memory of mystring is not freed by this code since the function returns
prior to reaching free(mystring). Whether you will run into memory leaks
depends on whether the memory is freed elsewhere in the program. Don't
confuse the scope of the local variable mystring with the scope of the thing
it points to. Your code should read as follows:

char *getString(void) {
char *mystring;

mystring = (char *) malloc(80* sizeof(char));
return(mystring);
}

void main(void) {
char *myName;

myName = getString();

if (myName != NULL) {
strcpy(myName, "Bill Clinton");
printf("%s\n", myName);
free(myName);
}
}

When getString() returns, mystring goes out of scope. But note that what the
function returns is a pointer to a 80-character memory chunk. After that
note that I make sure that main() calls free() to release the memory chunk
once I'm done with it.

I hope this helps
ipo

 

[Jack Klein]

****DON'T TOP POST. New material you add belongs after quoted
material you are referring to. If you want to use Microsoft's
brain-dead virus spreading and posting software (free, and not worth
its price), then YOU need to make the extra effort to put the cursor
where it belongs before you start typing.

The memory of mystring is not freed by this code since the function returns
prior to reaching free(mystring). Whether you will run into memory leaks
depends on whether the memory is freed elsewhere in the program. Don't
confuse the scope of the local variable mystring with the scope of the thing
it points to. Your code should read as follows:

NO IT SHOULD NOT READ AS FOLLOWS. Your example contains examples of
both poor C programming practice and undefined behavior.

char *getString(void) {
char *mystring;

mystring = (char *) malloc(80* sizeof(char));

Poor practices:

1. NEVER cast the pointer returned by malloc() in C. It is not
necessary if <stdlib.h> has been included, and can hide a valuable
warning if <stdlib.h> has not been included.

2. By definition, sizeof(char) in C is 1. It always has been, and
always will be. Multiplying by sizeof(char) is always unnecessary and
obfuscating.

Instead code the line above:

mystring = malloc(80 * sizeof *mystring);

Now the code is bullet-proof, even if you change the type of mystring
to be a pointer to something else larger than 1 byte.

And now your compiler is required to issue a diagnostic if you did not

return(mystring);
}

void main(void) {

Apparently you are talking about some language other than C, no matter
how much it looks like C. I understand that "void main()" is correct
Java, for example, but it is not legal C. main() returns an int in C.

char *myName;

myName = getString();

if (myName != NULL) {
strcpy(myName, "Bill Clinton");
printf("%s\n", myName);
free(myName);
}
}

When getString() returns, mystring goes out of scope. But note that what the
function returns is a pointer to a 80-character memory chunk. After that
note that I make sure that main() calls free() to release the memory chunk
once I'm done with it.

I hope this helps
ipo

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[ipo]

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
for malloc() if stdlib.h is not included.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.
ipo

43:52 GMT, "ipo"]
wrote in comp.lang.c:

****DON'T TOP POST. New material you add belongs after quoted
material you are referring to. If you want to use Microsoft's
brain-dead virus spreading and posting software (free, and not worth
its price), then YOU need to make the extra effort to put the cursor
where it belongs before you start typing.

The memory of mystring is not freed by this code since the function returns
prior to reaching free(mystring). Whether you will run into memory leaks
depends on whether the memory is freed elsewhere in the program. Don't
confuse the scope of the local variable mystring with the scope of the thing
it points to. Your code should read as follows:

NO IT SHOULD NOT READ AS FOLLOWS. Your example contains examples of
both poor C programming practice and undefined behavior.

char *getString(void) {
char *mystring;

mystring = (char *) malloc(80* sizeof(char));

Poor practices:

1. NEVER cast the pointer returned by malloc() in C. It is not
necessary if <stdlib.h> has been included, and can hide a valuable
warning if <stdlib.h> has not been included.

2. By definition, sizeof(char) in C is 1. It always has been, and
always will be. Multiplying by sizeof(char) is always unnecessary and
obfuscating.

Instead code the line above:

mystring = malloc(80 * sizeof *mystring);

Now the code is bullet-proof, even if you change the type of mystring
to be a pointer to something else larger than 1 byte.

And now your compiler is required to issue a diagnostic if you did not

return(mystring);
}

void main(void) {

Apparently you are talking about some language other than C, no matter
how much it looks like C. I understand that "void main()" is correct
Java, for example, but it is not legal C. main() returns an int in C.

char *myName;

myName = getString();

if (myName != NULL) {
strcpy(myName, "Bill Clinton");
printf("%s\n", myName);
free(myName);
}
}

When getString() returns, mystring goes out of scope. But note that what the
function returns is a pointer to a 80-character memory chunk. After that
note that I make sure that main() calls free() to release the memory chunk
once I'm done with it.

I hope this helps
ipo

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq[/QUOTE]

 

[fb]

ipo wrote:

Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.
ipo

I'm very sure he has. Have you? Also I think the latest C standard
would help you out.

I can't believe ignorance such as yours exists in this world.

Loser.

 

[Jarno A Wuolijoki]

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Since sizeof returns the size of an object in units of char don't you
think you should multiply it with another sizeof(char)?

 

[Allan Bruce]

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
for malloc() if stdlib.h is not included.

Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Then this is surely not what you want, but no error will be raised.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

You have a very strange machine indeed. The standard defines the size of a
char is 1 Byte, however a byte doesnt have to be 8 bits.

Allan

 

[Martin Ambuhl]

ipo wrote:

[...]

Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
for malloc() if stdlib.h is not included.

Troll alert #1

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Troll alert #2

Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.

Troll alert #3

Reserving plonk until I see if the humor gets any better.

 

[richard]

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

 

[Irrwahn Grausewitz]

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

It has a positive impact on code readability:

sizeof xyz

suggests that xyz is an /object/, whereas:

sizeof (abc)

suggests that abc is a /type/, as the construct:

sizeof (type)

is the only one where the parantheses are required.

Furthermore: note the blank between "sizeof" and "(...)" :
sizeof is an operator, not a function.

Irrwahn

 

[Richard Delorme]

richard a écrit :

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

sizeof is an operator and not a function. IMHO, avoiding the parentheses
makes the nature of sizeof clearer.

 

[Richard Heathfield]

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?

 

[Peter Nilsson]

....

Furthermore: note the blank between "sizeof" and "(...)" :

What of it?

sizeof is an operator, not a function.

Some people's style is to code with spaces between the function name and the
parenthesised argument list. It's not my preference, but there's nothing
syntactically wrong with it.

 

[richard]

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?

because there are no cases in c in which ((whatever)) adds anything to
(whatever). There are cases in which (whatever) is better than whatever.

 

[Peter Nilsson]

....

Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Then this is surely not what you want, but no error will be raised.

Missing semicolons aside, this does require a diagnostic.

You appear to be arguing the case *for* malloc casting.

 

[Allin Cottrell]

because there are no cases in c in which ((whatever)) adds anything to
(whatever). There are cases in which (whatever) is better than whatever.

True, but in this case the absence of parentheses is a marker of
a good understanding of what's going on -- namely that "sizeof"
is not a function, and does not require parentheses if its
operand is an object (rather than a type). Compare

double *x;

/* below: not recommended, but the parentheses are needed */
x = malloc(10 * sizeof(double));

/* recommended, and parentheses would be redundant */
x = malloc(10 * sizeof *x);

 

[ipo]

Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Do you test your code before posting it? It seems not. Not only the compiler
will give you an error about incompatible types but it will also complain
about the missing semicolons.

 

[Richard Heathfield]

because there are no cases in c in which ((whatever)) adds anything to
(whatever). There are cases in which (whatever) is better than whatever.

It is true that such cases exist - for example, to resolve apparent
precedence ambiguities (for the maintainer, of course, not for the
compiler, which we can assume will get the precedence correct without the
parentheses).

But what specific advantage does enclosing *mystring in parentheses add?

 

[Richard Heathfield]

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value.

Wrong. There is plenty wrong with it. All code should either do something
good or stop something bad happening. A malloc cast does neither. What it
/can/ do, however, is prevent you from being told that something bad has
happened. Therefore, it confers no advantage and yet suffers from a
possible disadvantage. Therefore, there is no good reason to include it.

In case you did not know,
stdlib.h has nothing to do with casting.

Jack knows that full well. Your inability to understand his point does not
constitute a failure of understanding on his part.

Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of
int for malloc() if stdlib.h is not included.

Wrong. If the cast is omitted without <stdlib.h> being included, the
compiler /must/ diagnose. If the cast is included, the diagnostic becomes
optional.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Wrong. The ISO C standard requires sizeof(char) to evaluate to 1 in all
cases.

Finally, whoever told you that void main(void) is not valid C?

Whoever told you it was?

I recommend
you get a copy of K&R and read it.

Feel free to provide a page reference to a void main(void) program in K&R.
You won't find one, but the read might do you some good.