i come from china,and i'm sorry that my english is very poor.
now i'm studing data structure and i met some problem about c language.
could you tell me what will happen after i use free()? i mean once i
use free() on a pointer,what will the pointer points to ?
for example:
#include<stdio.h>
#include<stdlib.h>
void main()
{
int *p;
if(!p) printf("good");
else printf("fail");
p=(int *)malloc(100);
if(p) printf("\n\ngood");
else printf("\n\nfail");
free(p);
if(!p) printf("\n\ngood");
else printf("\n\nfail");
*p=100;
printf("\n\n%d",*p);
}
the result is:
fail
good
fail
100
why?
Mar 16 '06
67 3697
On Sun, 19 Mar 2006 17:58:58 UTC, Jordan Abel <ra*******@gmail.com>
wrote: On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote: On Sun, 19 Mar 2006 11:27:39 UTC, Mark McIntyre <ma**********@spamcop.net> wrote:
On Sun, 19 Mar 2006 08:54:20 +0000 (UTC), in comp.lang.c , "Herbert Rosenau" <os****@pc-rosenau.de> wrote:
> (<any cast>) malloc() results in >undefined behavor, p=malloc() is the only secure call allowed in C.
Rubbish. Inserting a cast before malloc is not needed, but doesn't result in UB. You should program under an environment that would use for return valuses of different types different locations and then use casting on functions returning other than int, forgetting to #include stdlib you gets undefined behavior
The undefined behavior is not caused by the cast, and would happen without it.
So far so right - but it will hide the diagnostic that would at least
help to fix the problem, even as the diagnostic message itself may
irretate an beginner. The cast will noways able to fix the real
problem and is at least a problem on itself. >There is under absolutely no circomstance a need for a cast of (void*) >to anything else.
variadic functions?
That'd be more likely to need to be a cast TO void * than FROM void *. Or a cast of a null pointer constant, which could just as easily be 0 as (void*)0.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote: On Sun, 19 Mar 2006 17:55:16 UTC, Jordan Abel <ra*******@gmail.com> wrote:
> I still don't think casting the result off `malloc()` results in > undefined behaviour. Why would it? Remember, we were talking about > casting to a different /pointer/ type, not just /any/ type.
Correct. If the cast masks an error message, the undefined behavior has already happened.
No, the cast is to hide any diagnostic - it is still a lie to the compiler.
The cast is not the lie. The implicit declaration is the lie.
On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote: On Sun, 19 Mar 2006 15:12:17 UTC, ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <wm***************************@URANUS1.DV-ROSENAU.DE>, Herbert Rosenau <os****@pc-rosenau.de> wrote:
>You should program under an environment that would use for return >valuses of different types different locations and then use casting on >functions returning other than int, forgetting to #include stdlib you >gets undefined behavior
Using malloc() without a declaration will cause undefined behaviour, but casting the result of malloc() will not. The main problem with casting it is that it may disguise the fact that it's not declared.
You're in error. Who guarantees that your compiler will give you exactly the same bits in the same meaning that malloc returns? There are many reasons why the cast of the result of the undecleard malloc give you something that is absolutely independant from the value malloc has given back to the caller -> undefined behavior is guaranteed.
The undefined behavior has ALREADY HAPPENED, though. The only undefined
behavior involved is the call to an incorrectly declared function.
Conversion from int to pointer is not itself undefined, it's
implementation-defined.
Herbert Rosenau opined: On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka" <no****@btopenworld.com> wrote:
Herbert Rosenau opined:
> On Sun, 19 Mar 2006 11:27:39 UTC, Mark McIntyre > <ma**********@spamcop.net> wrote: > >> On Sun, 19 Mar 2006 08:54:20 +0000 (UTC), in comp.lang.c , >> "Herbert Rosenau" <os****@pc-rosenau.de> wrote: >> >> > (<any cast>) malloc() results in >> >undefined behavor, p=malloc() is the only secure call allowed in >> >C. >> >> Rubbish. Inserting a cast before malloc is not needed, but >> doesn't result in UB. > > You should program under an environment that would use for return > valuses of different types different locations and then use > casting on functions returning other than int, Again, can you please elaborate /why/ you think this matters (physical storage of return values)?
C Standard C makes absolutely no assumption how an implementation should handle such things as returning values from functions. So each implementation does it in a way best resolved by the underlying hardware. Intel on on that aspect one of the littlest market ever seen even as M$ means that they have the mayority.
OK, I think where the disconnect is.
We both agree that casting the return from `malloc()` is a Bad Thing.
Where we seem to disagree seems to be where the UB comes from if
<stdlib.h> is not included.
You seem to think it's the cast that does it.
I, OTH, think that UB has already happened *before*, and independently
of the cast. Cast may just hide the diagnostic that may have warned
you of the problem. (FWIW, it does seem that a few other people here
share my view.)
< big snip > Apart from calling people names again, you also forgot to breathe. Your posts are increasingly resembling any of the dozens of definitions of flaming. You risk becoming a troll... That doesn't disturb me. Only trolls will name others who tries to teach a troll.
I may have over-reacted.
Here you'll see nearly dayly an idiot who means that casting to hide diagnostics is ok. True, many peoples coming here have learned that by reading defektive books, broken code from idiots, so I try to help them to get it right whenever I have free time to do so.
You seem to have quite a lot at the moment. ;-)
As this thread is running for more than a week now I get allergic to read again and again therin casting results returning from functions like malloc is ok.
I don't think anyone was arguing that. I know I wasn't.
It looks like there is a need to drum into somebody that casting is almost the wrongest method to resolve a problem.
It does have its uses, though.
Use cast only if you are absolutely sure that yor really needs the cast and after you have checked and rechecked again and again that you really knows what you does and not on the way to lie to the compiler. lie to the compiler and it will get its dreadful revange.
As others have pointed out, in the case we were discussing, it's not
the cast that is lying, rather not including <stdlib.h> is.
Myself had learned that more than 20 years ago even on K&RII by falling through cede inspections, failing on getting the results I expected before I learned how to use casts right. There was no usenet ready to learn from others.
Why does this suddenly reminds me of the Yorkshiremen joke... ;-)
--
BR, Vladimir
SERENDIPITY:
The process by which human knowledge is advanced.
* Herbert Rosenau <os****@pc-rosenau.de> wrote: Here you'll see nearly dayly an idiot who means that casting to hide diagnostics is ok. True, many peoples coming here have learned that by reading defektive books, broken code from idiots, so I try to help them to get it right whenever I have free time to do so.
Many people learn the malloc cast from K&R 2nd edition and this link
would help more than calling them idiots: http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html
Stefan Krah
In article <wm***************************@URANUS1.DV-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.de> wrote: You're in error. Who guarantees that your compiler will give you exactly the same bits in the same meaning that malloc returns? There are many reasons why the cast of the result of the undecleard malloc give you something that is absolutely independant from the value malloc has given back to the caller -> undefined behavior is guaranteed.
Using the return value from an undeclared malloc *at all* will produce
undefined behaviour. Even if you don't cast it. The cast doesn't make
the behaviour any more undefined.
Conside the following fragments covering all the possibilities of
whether malloc is declared and whether the result is cast:
(1) #include <stdlib.h>
...
int *p = malloc(sizeof(*p));
(2) #include <stdlib.h>
...
int *p = (int *)malloc(sizeof(*p));
(3) /* no declaration of malloc */
...
int *p = malloc(sizeof(*p));
(4) /* no declaration of malloc */
...
int *p = (int *)malloc(sizeof(*p));
Which ones produce undefined behaviour? Does the presence of the cast
make any difference?
-- Richard
"Herbert Rosenau" <os****@pc-rosenau.de> wrote: On Sun, 19 Mar 2006 17:58:58 UTC, Jordan Abel <ra*******@gmail.com> wrote:
On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote: On Sun, 19 Mar 2006 11:27:39 UTC, Mark McIntyre <ma**********@spamcop.net> wrote:
> On Sun, 19 Mar 2006 08:54:20 +0000 (UTC), in comp.lang.c , "Herbert > Rosenau" <os****@pc-rosenau.de> wrote: > > > (<any cast>) malloc() results in > >undefined behavor, p=malloc() is the only secure call allowed in C. > > Rubbish. Inserting a cast before malloc is not needed, but doesn't > result in UB.
You should program under an environment that would use for return valuses of different types different locations and then use casting on functions returning other than int, forgetting to #include stdlib you gets undefined behavior
The undefined behavior is not caused by the cast, and would happen without it.
So far so right - but it will hide the diagnostic that would at least help to fix the problem,
Of course. Nobody has denied this. What has been said all along is that
the cast _hides_, but does not itself _cause_, undefined behaviour.
Richard
CBFalconer <cb********@yahoo.com> writes: Herbert Rosenau wrote: "Vladimir S. Oka" <no****@btopenworld.com> wrote: ... snip ... Yes, since otherwise you won't be alerted by the compiler if you fail to #include <stdlib.h>.
Liar! Never ever cast the return value of a function returning void* - except you likes to land in the world of undefined behavior.
You are apparently trying to take over Dan Pops place in the pantheon of diplomatic c.l.c posters. Calling someone a liar is not going to get you very far. This is possibly a language barrier problem (which Dan never had). Maybe you meant to say "false" or "not so" or even "I disagree" etc.
Possibly he wants to indicate that Vladimir is lying not to the
audience, but to the compiler. But if so, that could be better put.
Arndt Jonasson opined: CBFalconer <cb********@yahoo.com> writes: Herbert Rosenau wrote: > "Vladimir S. Oka" <no****@btopenworld.com> wrote: > ... snip ... >> >> Yes, since otherwise you won't be alerted by the compiler if you >> fail to #include <stdlib.h>. > > Liar! Never ever cast the return value of a function returning > void* - except you likes to land in the world of undefined > behavior.
You are apparently trying to take over Dan Pops place in the pantheon of diplomatic c.l.c posters. Calling someone a liar is not going to get you very far. This is possibly a language barrier problem (which Dan never had). Maybe you meant to say "false" or "not so" or even "I disagree" etc.
Possibly he wants to indicate that Vladimir is lying not to the audience, but to the compiler. But if so, that could be better put.
Quite possibly. For some reason the disagreement continued long after I
have admitted to mistyping "yes" for "no" in the quote above (that
should also have been clear from the rest of the post, now snipped).
See elsethread...
--
BR, Vladimir
Don't I know you?
On 2006-03-20, Vladimir S. Oka <no****@btopenworld.com> wrote: Arndt Jonasson opined:
CBFalconer <cb********@yahoo.com> writes: Herbert Rosenau wrote: > "Vladimir S. Oka" <no****@btopenworld.com> wrote: > ... snip ... >> >> Yes, since otherwise you won't be alerted by the compiler if you >> fail to #include <stdlib.h>. > > Liar! Never ever cast the return value of a function returning > void* - except you likes to land in the world of undefined > behavior.
You are apparently trying to take over Dan Pops place in the pantheon of diplomatic c.l.c posters. Calling someone a liar is not going to get you very far. This is possibly a language barrier problem (which Dan never had). Maybe you meant to say "false" or "not so" or even "I disagree" etc. Possibly he wants to indicate that Vladimir is lying not to the audience, but to the compiler. But if so, that could be better put.
Quite possibly. For some reason the disagreement continued long after I have admitted to mistyping "yes" for "no" in the quote above (that should also have been clear from the rest of the post, now snipped).
The only other place in the rest of the post that would have clarified
was one word off from confirming the 'yes' and, since it was
sequentially later than the 'yes', was easily misread.
See elsethread...
On Sun, 19 Mar 2006 21:03:36 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote: Mark McIntyre <ma**********@spamcop.net> writes: On Sun, 19 Mar 2006 14:49:17 +0100, in comp.lang.c , "Richard G. Riley" <rg****@gmail.com> wrote: in this case I would ask you HOW you intend malloc to return different memory banks for different types considering you cant tell malloc what it is malloc'ing for.
You might want to read up on how early Motorola chips worked, before sounding off...
Richard's error, I think, was in assuming we were talking about different calls to malloc() returning their results in different registers. Reading about the M68K wouldn't clear that up.
No, but it might prove instructive nevertheless!
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jordan Abel opined: On 2006-03-20, Vladimir S. Oka <no****@btopenworld.com> wrote: Arndt Jonasson opined:
CBFalconer <cb********@yahoo.com> writes: Herbert Rosenau wrote: > "Vladimir S. Oka" <no****@btopenworld.com> wrote: > ... snip ... >> >> Yes, since otherwise you won't be alerted by the compiler if >> you fail to #include <stdlib.h>. > > Liar! Never ever cast the return value of a function returning > void* - except you likes to land in the world of undefined > behavior.
You are apparently trying to take over Dan Pops place in the pantheon of diplomatic c.l.c posters. Calling someone a liar is not going to get you very far. This is possibly a language barrier problem (which Dan never had). Maybe you meant to say "false" or "not so" or even "I disagree" etc.
Possibly he wants to indicate that Vladimir is lying not to the audience, but to the compiler. But if so, that could be better put.
Quite possibly. For some reason the disagreement continued long after I have admitted to mistyping "yes" for "no" in the quote above (that should also have been clear from the rest of the post, now snipped).
The only other place in the rest of the post that would have clarified was one word off from confirming the 'yes' and, since it was sequentially later than the 'yes', was easily misread.
Yes, yes, yes. I do admit that my original post was messed up. My
subsequent ones were (I hope) quite clear, but that didn't seem to be
good enough.
I'll drop it here.
--
BR, Vladimir
Newton's Fourth Law: Every action has an equal and opposite
satisfaction.
"Vladimir S. Oka" wrote: Jordan Abel opined:
.... snip ... The only other place in the rest of the post that would have clarified was one word off from confirming the 'yes' and, since it was sequentially later than the 'yes', was easily misread.
Yes, yes, yes. I do admit that my original post was messed up. My subsequent ones were (I hope) quite clear, but that didn't seem to be good enough.
I'll drop it here.
Not a chance with this crowd. They have their teeth sunk into you,
and will worry this nonsense into the ground and back several times
before letting it die.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
On Sun, 19 Mar 2006 21:47:23 UTC, "Vladimir S. Oka"
<no****@btopenworld.com> wrote: Herbert Rosenau opined:
On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka" <no****@btopenworld.com> wrote:
[snip] OK, I think where the disconnect is.
We both agree that casting the return from `malloc()` is a Bad Thing.
Where we seem to disagree seems to be where the UB comes from if <stdlib.h> is not included.
No.
You seem to think it's the cast that does it.
No, the cast hides the error and the diagnostic threout.
I, OTH, think that UB has already happened *before*, and independently of the cast. Cast may just hide the diagnostic that may have warned you of the problem. (FWIW, it does seem that a few other people here share my view.)
< big snip >
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
Herbert Rosenau opined: On Sun, 19 Mar 2006 21:47:23 UTC, "Vladimir S. Oka" <no****@btopenworld.com> wrote:
Herbert Rosenau opined:
> On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka" > <no****@btopenworld.com> wrote: [snip] OK, I think where the disconnect is.
We both agree that casting the return from `malloc()` is a Bad Thing.
Where we seem to disagree seems to be where the UB comes from if <stdlib.h> is not included.
No.
You seem to think it's the cast that does it.
No, the cast hides the error and the diagnostic threout.
OK. You win.
--
BR, Vladimir
This MUST be a good party -- My RIB CAGE is being painfully pressed up
against someone's MARTINI!!
"Vladimir S. Oka" <no****@btopenworld.com> writes: Herbert Rosenau opined:
On Sun, 19 Mar 2006 21:47:23 UTC, "Vladimir S. Oka" <no****@btopenworld.com> wrote:
Herbert Rosenau opined:
> On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka" > <no****@btopenworld.com> wrote: [snip] OK, I think where the disconnect is.
We both agree that casting the return from `malloc()` is a Bad Thing.
Where we seem to disagree seems to be where the UB comes from if <stdlib.h> is not included.
No.
You seem to think it's the cast that does it.
No, the cast hides the error and the diagnostic threout.
OK. You win.
In what sense does he "win"? He clearly said previously that the cast
causes undefined behavior. Now he's changed is story, but without
acknowleding his error.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote: "Vladimir S. Oka" <no****@btopenworld.com> writes: Herbert Rosenau opined:
.... snip ... No, the cast hides the error and the diagnostic threout.
OK. You win.
In what sense does he "win"? He clearly said previously that the cast causes undefined behavior. Now he's changed is story, but without acknowleding his error.
I interpret Vladimirs posting as "I'm tired of this pointless
argument".
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
CBFalconer opined: Keith Thompson wrote: "Vladimir S. Oka" <no****@btopenworld.com> writes: Herbert Rosenau opined: ... snip ... No, the cast hides the error and the diagnostic threout.
OK. You win.
In what sense does he "win"? He clearly said previously that the cast causes undefined behavior. Now he's changed is story, but without acknowleding his error.
I interpret Vladimirs posting as "I'm tired of this pointless argument".
Exactly.
This abominable thread already had my head spinning from trying to
figure out what /is/ his POV after all.
[I also suspect he changed his mind but wwouldn't admit to it.]
--
BR, Vladimir
There was a young man of Ostend
Who let a girl play with his end.
She took hold of Rover,
And felt it all over,
And it did what she didn't intend. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Brandon J. Van Every |
last post by:
What's better about Ruby than Python? I'm sure there's something. What is
it?
This is not a troll. I'm language shopping and I want people's answers. I
don't know beans about Ruby or have...
|
by: Reed L. O'Brien |
last post by:
I see rotor was removed for 2.4 and the docs say use an AES module
provided separately... Is there a standard module that works alike or
an AES module that works alike but with better encryption?...
|
by: typingcat |
last post by:
First of all, I'm an Asian and I need to input Japanese, Korean and so
on. I've tried many PHP IDEs today, but almost non of them supported
Unicode (UTF-8) file.
I've found that the only Unicode...
|
by: Deniz Bahar |
last post by:
I know the basic definition of a sequence point (point where all side
effects guaranteed to be finished), but I am confused about this
statement:
"Between the previous and next sequence point an...
|
by: Ramasubbu Ramasubramanian XR (AS/EAB) |
last post by:
What is memory leakage, could any one explain with sample code
|
by: Jason Huang |
last post by:
Hi,
Would someone explain the following coding more detail for me? What's the
( ) for?
CurrentText = (TextBox)e.Item.Cells.Controls;
Thanks.
Jason
|
by: Jake Barnes |
last post by:
In the course of my research I stumbled upon this article by Alex
Russel and Tim Scarfe:
http://www.developer-x.com/content/innerhtml/default.html
The case is made that innerHTML should never...
|
by: Tom |
last post by:
I have a function that restricts access to a page to logged in users.
When a user who isn't logged in goes to the page, it will dynamically
generate a login form.
I'm trying to use it in...
|
by: cat_dog_ass |
last post by:
....Microsoft ports the .NET framework to other operating systems? Will
the only advantage that Java has over .NET be lost?
I've been a Java programmer and will be shifting to .NET soon. Is this...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |