Will it leak the memory?

[KG]

Hi,
I do have a question.

int main()
{
char *p = (char *)malloc(9);

strcpy(p,"TajMahal");

p++;

free(p);

}

Does this program results in memory leak?
Please explain.

Regards,
Kiran Patil

 

[Chris Dollin]

Hi,
I do have a question.

int main()
{
char *p = (char *)malloc(9);

strcpy(p,"TajMahal");

p++;

free(p);

}

Does this program results in memory leak?

It results in undefined behaviour. The only legal arguments to `free`
are null and a pointer returned from malloc that hasn't been freed.

There's no way of telling what that does from the C standard.

If you omit the `p++`, then the program terminates with memory
still allocated. Whether this results in a memory leak depends
on (a) what you mean by "memory leak" and (b) what the surrounding
environment does when the program exits. It is /not/ specified that
all mallocated memory is "returned to the system".

 

[Mark Bluemel]

Hi,
I do have a question.

int main()
{
char *p = (char *)malloc(9);

You haven't included a valid prototype for malloc and your cast has
hidden a potentially value compiler diagnostic.

strcpy(p,"TajMahal");

p++;

free(p);

This results in undefined behaviour. The address you passed to free()
isn't an address of a a block of space allocated with malloc(), calloc()
or realloc().

}

Does this program results in memory leak?

If you're lucky the program will crash. If you're very unlucky, the
computer will grow arms, produce a knife and stab you.

Please explain.

Please explain why you felt it was appropriate to post this nonsense.

 

[Mark Bluemel]

KG wrote:

Hi,
I do have a question.

int main()
{
char *p = (char *)malloc(9);

strcpy(p,"TajMahal");

p++;

free(p);

}

Does this program results in memory leak?

It results in undefined behaviour. The only legal arguments to `free`
are null and a pointer returned from malloc that hasn't been freed.

There's no way of telling what that does from the C standard.

If you omit the `p++`, then the program terminates with memory
still allocated. [snip]

Did you really mean this?

 

[Richard Heathfield]

Mark Bluemel said:

KG wrote:

p++;

free(p);

}

Does this program results in memory leak?

It results in undefined behaviour. The only legal arguments to `free`
are null and a pointer returned from malloc that hasn't been freed.

There's no way of telling what that does from the C standard.

If you omit the `p++`, then the program terminates with memory
still allocated. [snip]

Did you really mean this?

In a sense, he might be right, but only if you squint and look at the
language in a funny way. Quoth the Stannit[1]:

"The free function causes the space pointed to by ptr to be deallocated,
that is, made available for further allocation."

So, from the program's perspective, the memory has been deallocated, so
he's wrong. But from the 'program + runtime library' perspective, it
could be (and has been) argued that free() must work in such a way as
to keep the memory available for further allocation *to the program*,
and therefore it remains allocated as far as the host system (e.g. the
OS) is concerned, at least until the program has terminated.

Some people think this is a powerful and meaningful argument, and others
think it's a load of fetid dingo kidneys[2]. Personally, I don't care
either way.

[1] http://en.wikipedia.org/wiki/Evening_Standard#Trivia
[2] http://www.bbc.co.uk/dna/h2g2/A76961

 

[Richard]

You haven't included a valid prototype for malloc and your cast has
hidden a potentially value compiler diagnostic.


This results in undefined behaviour. The address you passed to free()
isn't an address of a a block of space allocated with malloc(),
calloc() or realloc().


If you're lucky the program will crash. If you're very unlucky, the
computer will grow arms, produce a knife and stab
you. <http://www.xkcd.com/293/>

Oh god no. I wondered how long it would take before this became the new
"in joke" for your "undefined" warnings.

Look, it isn't funny because a toaster will NOT, under any
circumstances, grow arms and stab you. It might electrocute you.

Please explain why you felt it was appropriate to post this nonsense.

--

 

[Richard]

Mark Bluemel said:

KG wrote:

p++;

free(p);

}

Does this program results in memory leak?


It results in undefined behaviour. The only legal arguments to `free`
are null and a pointer returned from malloc that hasn't been freed.

There's no way of telling what that does from the C standard.

If you omit the `p++`, then the program terminates with memory
still allocated. [snip]

Did you really mean this?

In a sense, he might be right, but only if you squint and look at the
language in a funny way. Quoth the Stannit[1]:

Why would you say this? For the sake of this question he is totally
incorrect.

When he has called "free" the memory is then unavailable in any decent
program. End of subject.

 

[Richard Heathfield]

Richard said:

When he has called "free" the memory is then unavailable in any decent
program.

When he has called free, the memory is available for reallocation. But
you do have a point, in that it is perfectly reasonable to call it
"unavailable" too, in the sense that the program cannot use it again
unless *alloc returns a pointer to it again.

I covered all this in my earlier reply, which I recommend that you read.

.

End of subject.

Dream on. Neither you nor I decide when a Usenet subject is closed.

 

[Richard Heathfield]

Richard said:

Oh god no. I wondered how long it would take before this became the
new "in joke" for your "undefined" warnings.

Look, it isn't funny because a toaster will NOT, under any
circumstances, grow arms and stab you. It might electrocute you.

What you mean is that you don't think it's funny. But it is clear that
at least some others here do think it's funny. The Standard is silent
on the matter, so we are forced to resort to empirical observation and
statistical analysis. After some rather tedious number crunching, the
details of which need not concern us here, I can announce with 95%
confidence that the joke is at least 82% funny (+/- 0.5%).

 

[Richard]

Richard said:



When he has called free, the memory is available for reallocation. But
you do have a point, in that it is perfectly reasonable to call it
"unavailable" too, in the sense that the program cannot use it again
unless *alloc returns a pointer to it again.

I covered all this in my earlier reply, which I recommend that you
read.

I did. And am incredulous that yet again you seek to show off and
obfuscate. Why do it? Your knowledge of C is very good - but there are
certain things best left unsaid.

.

Dream on. Neither you nor I decide when a Usenet subject is closed.

It is the end of subject with regard to a nOOb asking that particular
question.
--

 

[Richard]

Richard said:


What you mean is that you don't think it's funny. But it is clear that
at least some others here do think it's funny. The Standard is silent
on the matter, so we are forced to resort to empirical observation and
statistical analysis. After some rather tedious number crunching, the
details of which need not concern us here, I can announce with 95%
confidence that the joke is at least 82% funny (+/- 0.5%).

"In jokes" amongst a group of smart ass cognoscenti are not funny - they
are tedious to the extreme. And of that, I am 100% assured :-;

 

[Richard Heathfield]

Richard said:

I did. And am incredulous that yet again you seek to show off and
obfuscate.

The comp.lang.c newsgroup is a mirror. What you see is what you bring
with you.

Why do it?

Precision, my dear chap - precision. Or at least the hope of it.

Your knowledge of C is very good

Yes, I know.

- but there are certain things best left unsaid.

Don't let that stop you from saying them. It hasn't yet.

 

[Richard Heathfield]

Richard said:

"In jokes" amongst a group of smart ass cognoscenti are not funny -

I wouldn't know. I don't know any smart ass cognoscenti. Asses are not
renowned for their smartness or their cognizance. In-jokes, however,
can be very funny indeed for those who are "in".

(Normally I don't approve of in-crowds, because they are by nature
exclusive. But techie in-crowds are different - there are no barriers
to entry except one's own unwillingness to learn.)

they are tedious to the extreme. And of that, I am 100% assured :-;

Well, as long as you're happy...

 

[Enzo Canuzzi]

I wouldn't know. I don't know any smart ass cognoscenti. Asses are not

renowned for their smartness or their cognizance.

So i am not sure about the cognizance part. With a broad definition of
cognizance and taken into acount that the asshole, which is a public
member of the ass class, has a dense nerve network of the sense of
touch. So as the ass takes cognizance of something going in or out, you
can define some sort of cognizance of the ass.

 

[Kenneth Brody]

So i am not sure about the cognizance part. With a broad definition of
cognizance and taken into acount that the asshole, which is a public
member of the ass class, has a dense nerve network of the sense of
touch. So as the ass takes cognizance of something going in or out, you
can define some sort of cognizance of the ass.

C doesn't have classes, let alone public/private members of such a
thing. Perhaps you want C++ instead?

--
+-------------------------+--------------------+-----------------------+
| 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]>

 

[Serve Lau]

I make gambling machines for a living, I can assure you we have the funniest
examples of undefined behaviour around.Well funny for the player, not the
programmer.
One example is that when a game started some memory was allocated with
malloc for a struct that has a function pointer in it which would be called
every second. The function would draw prizes (or 0) every second and store
them in static variables. Then when you leave the game and entered again the
struct would be allocated again etc. So when the allocation would fail
because of a memory leak somewhere else no new prizes would be generated and
the game would take the same prize every second, the ones last stored in the
static variables. So it could happen that a player would win a jackpot every
time he let the reels spin!
It's a player's dreeam to find bugs like that, but a game programmer's
nightmare.

 

[Martin Ambuhl]

Hi,
I do have a question.

int main()
{
char *p = (char *)malloc(9);

^^^^^^^^
This is bad form, perhaps brought on by your

strcpy(p,"TajMahal");

p++;

free(p);

^^^^^^^
This is an error. p does not contain a value returned from
malloc.

}

Does this program results in memory leak?

It results in any damn thing the implementation decides. If malloc
actually tries to free() space using the pointer p, which has a value
not returned from malloc, the most likely result is the complete
corruption of the memory management section.

And if free() did what some people naively hope it would, freeing some
space (of what size?) starting at one past the orignal value of p,
obviously at least one allocated char would not be freed.

Please explain.

The attempt to use free() with a pointer with a value not returned from
malloc is a gross error. There is no correct answer to your question
other than to say that the code is hopelessly broken.

 

[Keith Thompson]

Oh god no. I wondered how long it would take before this became the new
"in joke" for your "undefined" warnings.

Look, it isn't funny because a toaster will NOT, under any
circumstances, grow arms and stab you. It might electrocute you.

Well then, I'll make sure to limit my future attempts at humor to
things that can plausibly happen in real life.

Let's see now ...

A guy walks into a bar. He orders a drink, drinks it, pays for it,
and leaves.

HAHAHAHAHAHAHAHAHA!!

The nasal demons metaphor has been explained here before, but if you
still don't get it, I'm sure someone would be willing to explain it to
you again.

Until then, consider this. Users often make assumptions about what a
program or system cannot possibly do. Such assumptions are frequently
wrong. This does not imply that a C program can make demons fly out
of your nose, or that at toaster can grow an arm and stab you, merely
that assumptions about what a system cannot possibly do are frequently
wrong. This has real-world consequences; for example, malware often
works by taking advantage of such assumptions.

 

[Clever Monkey]

Oh god no. I wondered how long it would take before this became the new
"in joke" for your "undefined" warnings.

Look, it isn't funny because a toaster will NOT, under any
circumstances, grow arms and stab you. It might electrocute you.

That is one sort of undefined behaviour. You can't guarantee that a
toaster will not grow arms and stab you. Sure, it's highly /unlikely/,
but this is why it is funny when it does happen.

Otherwise, we are just laughing at a a guy who was stabbed in the face.
This is not funny. What were you thinking?

Again: UB is UB. You can put any real parameters around UB. It is
still within the realm of all the possibilities that UB will result in
purple monkeys flying out of one's ass, which is the standard
measurement of undefined behaviour around here.

I think I'd rather take my chances with the toaster, but undefined
behaviour means we /can't make that choice/.

 

[Richard Bos]

So i am not sure about the cognizance part. With a broad definition of
cognizance and taken into acount that the asshole,

You cut a hole in your ass? What has the poor animal done to deserve
such treatment?

which is a public member of the ass class, has a dense nerve network
of the sense of touch.

Well, I bet it does! _You_ would have sore nerves, too, if someone cut a
hole in you.

So as the ass takes cognizance of something going in or out,

And now you're torturing the poor dear by taking things in and out of
it? That's torture, that is. I'm calling the RSPCA on you.

Richard