Hi,
This is c code , but the question is same to c++ £¨new/delete£©.
char* p = malloc(10);
strcpy(p, "hello");
printf("%s\n", p);
free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
p = NULL; // If we do not use p after call free , we can delete this line
..
And someone write p = NULL is not a good idea for Unix.
Thanks.
35  2742 
"fcvcnet" <fc*****@163.com> skrev i meddelandet
news:e2**********@news.cn99.com... Hi,
This is c code , but the question is same to c++ £¨new/delete£©.
char* p = malloc(10);
strcpy(p, "hello");
printf("%s\n", p);
free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
p = NULL; // If we do not use p after call free , we can delete this
line .
And someone write p = NULL is not a good idea for Unix.
Thanks.
Hello,
This does not answer your question byt why replace the code with the
following?
printf("%s\n","hello");
Regards,
Peter Jansson http://www.jansson.net/
Hi,
Do you mean "byt why not replace the code with the following?" ?
If it is , I think use "p" instead of "hello" is simple.
And I think if use "hello" , the compiler will allocate a chunck of memory
to hold "hello".
Hi,
Can somebody introduce any book about c++ with memory, I have so many
question about this part.
Thank you very much.
fcvcnet wrote: Hi,
This is c code , but the question is same to c++ £¨new/delete£©.
char* p = malloc(10);
malloc returns void * pointer, so the statement is changed into:
char *p = (char *)malloc(10);
free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
p = NULL; // If we do not use p after call free , we can delete thisline
.
you can wrap the free function that has this ability, but the argument
is the reference to the pointer.
void free_wrapper (void **pp)
{
free ( *pp );
*pp = NULL;
}
And someone write p = NULL is not a good idea for Unix.
Why? I think NULL is a cleaner way to stand for Null pointer than 0 or
(void *)0 at least.
But for C++, it is a good point to introduce null object design
pattern instead of NULL.
fcvcnet wrote: Hi,
This is c code , but the question is same to c++ £¨new/delete£©.
char* p = malloc(10);
Don't use malloc, use new.
strcpy(p, "hello");
printf("%s\n", p);
Why not printf("hello\n"); ?
free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
Because you pass the pointer by value, so free() can't change the value
of the pointer.
p = NULL; // If we do not use p after call free , we can delete this line
..
And someone write p = NULL is not a good idea for Unix.
Who and where?
--
Ian Collins.
yes, I reference from http://users.actcom.co.il/~choo/lupg...x-memory.html#
c_alloc char* p = malloc(10);
And someone write p = NULL is not a good idea for Unix.
Why? I think NULL is a cleaner way to stand for Null pointer than 0 or
(void *)0 at least.
But for C++, it is a good point to introduce null object design
pattern instead of NULL.
sorry , I am wrong , I made a mistake of this.
"fcvcnet" <fc*****@163.com> skrev i meddelandet
news:e2**********@news.cn99.com... Hi,
Do you mean "byt why not replace the code with the following?" ?
If it is , I think use "p" instead of "hello" is simple.
And I think if use "hello" , the compiler will allocate a chunck of memory
to hold "hello".
Hi,
Yes, I did mean "...but why not replace..."
The compiler will also allocate a chunck of memory to hold "hello" for the
following part of your code:
strcpy(p, "hello");
Regards,
Peter Jansson http://www.jansson.net/
Thanks. Because you pass the pointer by value, so free() can't change the value
of the pointer.
now I know. And someone write p = NULL is not a good idea for Unix.
Who and where?
sorry for that I made a mistake.
BTW, Can I edit/delete the news I have had posted for there is a mistake I
made and that bring much more misunderstand?
>BTW, Can I edit/delete the news I have had posted for there is a mistake I made and that bring much more misunderstand?
No.
Regarding the p=NULL issue, if the pointer object goes out of scope it
indeed is redundant. The language doesn't guard against this kind of
stuff: you have to keep track manually what is freed and what isn't
(likewise, what is allocated and what isn't). This is why it's a good
idea generally to zero pointers to memory that is already freed (to
avoid freeing the same memory twice or more).
But, if the pointer goes out of scope, knock yourself out and not zero
it.
One more thing, goes without saying but saying it anyway. If you zero
pointer to memory that is freed, you easily propagate the information
to other parts of your program that the pointer doesn't point to valid
memory. (there must be someway to do this, and zeroing the pointer is
the obvious way).
fcvcnet wrote: Hi,
Do you mean "byt why not replace the code with the following?" ?
If it is , I think use "p" instead of "hello" is simple.
The write:
char* p = "hello";
And I think if use "hello" , the compiler will allocate a chunck of memory
to hold "hello".
Yes, but it will do that either way. Somewhere in memory, there has to be
the "hello". Your version just dynamically allocates a second chunk of
memory and then copies the "hello" over to that. Later, it deallcates the
memory again. So you do much more work than needed.
dan2online wrote: And someone write p = NULL is not a good idea for Unix.
Why? I think NULL is a cleaner way to stand for Null pointer than 0 or
(void *)0 at least.
Maybe it would. However, NULL is not a null pointer. It's an integer
constant (actually a macro that is replaced by one).
But for C++, it is a good point to introduce null object design
pattern instead of NULL.
AFAIK, the next version of the C++ standard will address this issue.
fcvcnet wrote: Thanks.
Because you pass the pointer by value, so free() can't change the value
of the pointer.
now I know. > And someone write p = NULL is not a good idea for Unix.
>
Who and where?
sorry for that I made a mistake.
BTW, Can I edit/delete the news I have had posted for there is a mistake
I made and that bring much more misunderstand?
Yes. Newsreaders usually offer functionality to cancel a posting as well as
supersede one. However, some usenet servers don't seem to handle it
correctly, so your message might not be canceled completely.
Rolf Magnus wrote: fcvcnet wrote:
Hi,
Do you mean "byt why not replace the code with the following?" ?
If it is , I think use "p" instead of "hello" is simple.
The write:
char* p = "hello";
And I think if use "hello" , the compiler will allocate a chunck of memory
to hold "hello".
Yes, but it will do that either way. Somewhere in memory, there has to be
the "hello". Your version just dynamically allocates a second chunk of
memory and then copies the "hello" over to that. Later, it deallcates the
memory again. So you do much more work than needed.
My understanding of the OP's question was why you after delete p should
set p to 0. The silly code between new and delete (well - malloc and
free, but the op explains the problem is the same in both cases) was
just more or less random bits of code.
/Peter
With C++ it's simple. If You delete 0 then delete does nothing.
BTW. delete p;
p = 0; // or NULL
Can be changed to:
delete p, 0;
>Maybe it would. However, NULL is not a null pointer. It's an integer constant (actually a macro that is replaced by one).
Better to say that in C it can be macro. In C++ it should be #defined
as just 0. With no type. AFAIK Stroustrup votes for 0 and not NULL
since once can accidentally include file with invalid or old style NULL
definition.
Dervish <DA*******@yandex.ru> wrote: Maybe it would. However, NULL is not a null pointer. It's an integer
constant (actually a macro that is replaced by one).
Better to say that in C it can be macro. In C++ it should be #defined
as just 0.
....which is a macro.
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
Dervish wrote: Maybe it would. However, NULL is not a null pointer. It's an integer
constant (actually a macro that is replaced by one).
Better to say that in C it can be macro.
I didn't talk about C, since we're in a C++ newsgroup.
In C++ it should be #defined as just 0. With no type.
First of all, 0 does have a type. Any expression has a type. The type of
literal 0 is int. Second, NULL can be defined as anything that resolves to
a constant integral expression with the value 0, so
#define NULL (4 + 3 - 7)
would also be ok.
AFAIK Stroustrup votes for 0 and not NULL since once can accidentally
include file with invalid or old style NULL definition.
He votes for 0, because NULL is supposed to be only used in pointer context,
but still is an integer, which can sometimes lead to unexpected results.
When using 0 directly, the fact that it's an integer is not hidden.
Consider:
#include <iostream>
void f(int)
{
std::cout << "f(int) called\n";
}
void f(char*)
{
std::cout << "f(char*) called\n";
}
int main()
{
f(NULL); // oops, calls f(int)
}
You would have to cast NULL to char* to get the correct result, which is
less obvious than the fact that you need to cast literal 0.
Another problem (though more relevant to C than C++) is that you have to be
careful with functions with variable argument lists, because you have to
cast NULL to a pointer here too if you actually want to pass a pointer.
If a function like
void f(const char* p, ...);
expects pointers to char until there is a null pointer, you would have to
write:
f("hello", "world", "this", "is", "a", "test", (char*)NULL);
If you use NULL without the cast, the behavior is undefined because you pass
the wrong type.
"fcvcnet" <fc*****@163.com> wrote in message
news:e2**********@news.cn99.com... Hi,
This is c code , but the question is same to c++ £¨new/delete£©.
char* p = malloc(10);
strcpy(p, "hello");
printf("%s\n", p);
free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
p = NULL; // If we do not use p after call free , we can delete this
line
.
And someone write p = NULL is not a good idea for Unix.
Thanks.
Here is the answer from the perspective of the C++ delete operator: http://public.research.att.com/~bs/b...ml#delete-zero
I would say the same considerations apply to malloc.
Cy
Rolf Magnus wrote: fcvcnet wrote:
Thanks.
Because you pass the pointer by value, so free() can't change the value >> of the pointer. now I know. > And someone write p = NULL is not a good idea for Unix.
>
Who and where?
sorry for that I made a mistake.
BTW, Can I edit/delete the news I have had posted for there is a
mistake I made and that bring much more misunderstand?
Yes. Newsreaders usually offer functionality to cancel a posting as
well as supersede one. However, some
Most.
usenet servers don't seem to
handle it correctly,
Ignore cancel and supercede requests due to forging.
so your message might not be canceled completely.
It's best to assume that whatever you wrote is the way it is. If you
make a mistake, post a follow-up with the correction.
Brian
Ian Collins wrote: fcvcnet wrote: free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
Because you pass the pointer by value, so free() can't change the value
of the pointer.
Actually free() does change the value of the pointer. It's a bit of
an oddball function. (After the call, the pointer's value is
indeterminate; before the call, it wasn't).
Old Wolf wrote: Ian Collins wrote:
fcvcnet wrote:
free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
Because you pass the pointer by value, so free() can't change the value
of the pointer.
Actually free() does change the value of the pointer. It's a bit of
an oddball function. (After the call, the pointer's value is
indeterminate; before the call, it wasn't).
I didn't know that, where is this behaviour documented?
The C standard make no mention of this.
--
Ian Collins.
Ian Collins wrote: Actually free() does change the value of the pointer. It's a bit of
an oddball function. (After the call, the pointer's value is
indeterminate; before the call, it wasn't).
I didn't know that, where is this behaviour documented?
free() don't change no value of no stinkin' pointer.
Read the thread "Deleting and checking pointers" for a nauseatingly in-depth
analysis of 'delete'. In sumary:
- delete is not required to not change its pointer
- the bits of other pointers to the same memory shall not change
- reading any of those pointers - except thru their addresses
typecast to unsigned char * - is undefined behavior because
the pointer might live in a hardware register that no longer
contains the address of a valid memory location
If I have confused any parts of this list, blame that thread...
The C standard make no mention of this.
I expect the second two could apply...
--
Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Rolf Magnus wrote: Dervish wrote: AFAIK Stroustrup votes for 0 and not NULL since once can accidentally
include file with invalid or old style NULL definition.
He votes for 0, because NULL is supposed to be only used in pointer context,
but still is an integer, which can sometimes lead to unexpected results.
When using 0 directly, the fact that it's an integer is not hidden.
Consider:
#include <iostream>
void f(int)
{
std::cout << "f(int) called\n";
}
void f(char*)
{
std::cout << "f(char*) called\n";
}
int main()
{
f(NULL); // oops, calls f(int)
}
You would have to cast NULL to char* to get the correct result, which is
less obvious than the fact that you need to cast literal 0.
Isn't the above argument the equivalent of saying that Stroustrup was
wrong to use 0 instead of (void*)0 ?
--
Ron House ho***@usq.edu.au http://www.sci.usq.edu.au/staff/house
Old Wolf wrote: Ian Collins wrote: fcvcnet wrote: free(p);
// free just add p to the free list of memory, and do nothing else.
// Is there any use of p? If we never use p why not just nullify p in
free()?
Because you pass the pointer by value, so free() can't change the value
of the pointer.
Actually free() does change the value of the pointer.
It doesn't. It even can't.
It's a bit of an oddball function. (After the call, the pointer's value is
indeterminate; before the call, it wasn't).
No. The pointer's value is exactly the same as before. However, the object
that it was pointing to is gone.
If you write a letter, and the house that it's supposed to go to is knocked
down, that won't magically change the address written on the letter.
However, it will be invalid, because there is no house at that address
anymore. It's just the same with a pointer to a destroyed object.
Rolf Magnus wrote: Actually free() does change the value of the pointer.
No. The pointer's value is exactly the same as before.
Are you completely sure? What if the pointer lived in a register that
twitched, or something, when the memory it pointed to got changed?
(The example for free() was raised that a segment-offset system, with two
values for each pointer, could become invalid when the OS releases the
segment. Not the same as changing the pointer value, but pretty danged
close.)
--
Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Phlip wrote: Actually free() does change the value of the pointer. No. The pointer's value is exactly the same as before.
Are you completely sure? What if the pointer lived in a register that
twitched, or something, when the memory it pointed to got changed?
In this case the hardware is modifying the pointer, not free. You can also
have an int variable that lives in a memory address that is incremented
when is read. If your c++ compiler creates that type of things without some
special way to ask for it, is not a standard conforming compiler.
(The example for free() was raised that a segment-offset system, with two
values for each pointer, could become invalid when the OS releases the
segment. Not the same as changing the pointer value, but pretty danged
close.)
Reasoning that way, if you have an i integer variable used as index in a
string, if you erase the content of the string you are pretty close to
change the value of i. Can be seen that way, but it is confusing, the value
of i has no changed at all. You can explain that situation by saying that
the index has been invalidated, and nobody will be confused.
--
Salu2
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Julián Albo wrote: (The example for free() was raised that a segment-offset system, with two
values for each pointer, could become invalid when the OS releases the
segment. Not the same as changing the pointer value, but pretty danged
close.)
Reasoning that way, if you have an i integer variable used as index in a
string, if you erase the content of the string you are pretty close to
change the value of i. Can be seen that way, but it is confusing, the
value of i has no changed at all. You can explain that situation by saying
that the index has been invalidated, and nobody will be confused.
In the segment-offset situation, when the pointer is read as an rvalue,
hardware might assemble the segment and offset into a composite thing. This
is a common form of virtual memory. So an invalid segment or offset might
cause a memory exception.
(Of course these issues are leaving us MS Windows developers salivating for
a C++ implementation that actually occassionally returns memory to the OS
at 'delete' time. Many implementations just grow and grow forever!)
--
Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Phlip wrote: In the segment-offset situation, when the pointer is read as an rvalue,
hardware might assemble the segment and offset into a composite thing.
This is a common form of virtual memory. So an invalid segment or offset
might cause a memory exception.
I don't see why the compiler needs to do that if you are only doing
something with the value of the pointer but not dereferecing it. It is
always possible, and probably more efficient, to work with the composite
without using segment registers. I don't think any compiler writer will
violate standards and programmers expectations for no benefit.
--
Salu2
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Julián Albo wrote: Phlip wrote:
In the segment-offset situation, when the pointer is read as an rvalue,
hardware might assemble the segment and offset into a composite thing.
This is a common form of virtual memory. So an invalid segment or offset
might cause a memory exception.
I don't see why the compiler needs to do that if you are only doing
something with the value of the pointer but not dereferecing it.
In C++, you don't pay for what you don't use. Generally.
Consider a slow opcode FOO that carefully copied out the segment and offset
from such a hypothetical pointer. Suppose this CPU also had a fast opcode
BAR that exploited the CPU's microcode to copy out the pointer's value, but
this BAR threw an automatic hardware exception if the segment and offset
are not valid.
(Such hardware exceptions are often how overcommitted virtual memory works.)
A C++ compiler cannot guess which pointers are valid and which should not be
used as rvalues. This code causes undefined behavior:
int * p = new int;
delete p;
assert(NULL != p); // <-- undefined behavior
Our hypothetical compiler must use the BAR opcode in that assertion, because
all the times we use pointers for defined behavior must be fast.
(BTW the assertion itself is well-formed, and won't cause the first
undefined behavior.)
--
Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Rolf Magnus wrote: If a function like
void f(const char* p, ...);
expects pointers to char until there is a null pointer, you would have to
write:
f("hello", "world", "this", "is", "a", "test", (char*)NULL);
If you use NULL without the cast, the behavior is undefined because you pass
the wrong type.
NULL can be considered as one kind of MARK, so the programmer will
decide what action to do, I think.
dan2online wrote: Rolf Magnus wrote: If a function like
void f(const char* p, ...);
expects pointers to char until there is a null pointer, you would have to
write:
f("hello", "world", "this", "is", "a", "test", (char*)NULL);
If you use NULL without the cast, the behavior is undefined because you
pass the wrong type.
NULL can be considered as one kind of MARK, so the programmer will
decide what action to do, I think.
The ellipses operator ... is type-hostile. A NULL might go in as an int, not
a pointer, and might be the wrong size. A programmer cannot control this
situation, though I suspect it will appear to work correctly (and vaguely
lie within the realm of defined behavior) on platforms where ints and
pointers are the same size.
Whoever suggested ... is advised to simply provide default arguments for as
many strings as they need:
void f (
char const * p1,
char const * p2 = NULL,
char const * p3 = NULL,
char const * p4 = NULL,
char const * p5 = NULL,
char const * p6 = NULL,
char const * p7 = NULL,
char const * p8 = NULL,
char const * p9 = NULL
);
--
Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Phlip wrote: Consider a slow opcode FOO that carefully copied out the segment and
offset from such a hypothetical pointer. Suppose this CPU also had a fast
opcode BAR that exploited the CPU's microcode to copy out the pointer's
value, but this BAR threw an automatic hardware exception if the segment
and offset are not valid.
Too much suppositions for a reasonable discussion. I'm sure you can imagine
an architecture where your idea makes sense, but I don't think real code
for existent machines must be invalidated for the convenience of imaginary
ones.
--
Salu2
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Phlip wrote: Rolf Magnus wrote:
Actually free() does change the value of the pointer.
No. The pointer's value is exactly the same as before.
Are you completely sure? What if the pointer lived in a register that
twitched, or something, when the memory it pointed to got changed?
This must have been said elsewhere before: free() receives the pointer by
value. Thus, we have two pointer objects and the one that free() could
change easily is its local copy. Whether it does that appears to be an
implementation detail not observable from the outside.
On the other hand, if p is a pointer variable the call free(p) will release
the memory and invalidate the pointer. After that, any lvalue-rvalue
conversion on p is undefined behavior. In other words, even if free() would
somewhat magically alter the content of the object p (by guessing its
address or tracing all pointer objects that point to the released region),
you would have no means of finding out. Any attempt will result in
undefined behavior as reading out the content of p is an unholy act.
Best
Kai-Uwe Bux This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Agoston Bejo |
last post by:
I want to enforce such a constraint on a column that would ensure that the
values be all unique, but this wouldn't apply to NULL values. (I.e. there
may be more than one NULL value in the column.)...
|
by: iStrain |
last post by:
Hiya. I'm _sure_ this is an FAQ, but Googling hasn't produced the
answer in a way I can make sense out of. I know I should get this, but
so far no way...
I'm creating tables and doing queries in...
|
by: Mike MacSween |
last post by:
This as the row source for a combo:
SELECT qryRole.RoleID, qryRole.Role
FROM qryRole
WHERE (((qryRole.RoleID) Not In (SELECT RoleID FROM qryRoleEvent INNER JOIN
qryEvent ON qryRoleEvent.EventID...
|
by: sathyashrayan |
last post by:
The standard confirms that the following initialization of a struct
struct node
{
---
---
}
struct node var = {NULL};
|
by: junky_fellow |
last post by:
Can 0x0 be a valid virtual address in the address space
of an application ?
If it is valid, then the location pointed by a NULL pointer
is also valid and application should not receive "SIGSEGV"...
|
by: Jason Curl |
last post by:
I've been reading this newsgroup for some time and now I am thoroughly
confused over what NULL means.
I've read a NULL pointer is zero (or zero typecast as a void pointer),
others say it's...
|
by: David Sworder |
last post by:
Hi,
I've created a UserControl-derived class called MyUserControl that is
able to persist and subsequently reload its state. It exposes two methods as
follows:
public void Serialize(Stream...
|
by: yossi.kreinin |
last post by:
Hi!
There is a system where 0x0 is a valid address, but 0xffffffff isn't.
How can null pointers be treated by a compiler (besides the typical
"solution" of still using 0x0 for "null")?
-...
|
by: Aaron Morton |
last post by:
I'm working on a IHttpModule that handles the PreSendRequestHeaders event
from the HttpApplication, if the event is raised after EndRequest then
HttpContext.Current is null. If it is raised before...
|
by: lovecreatesbea... |
last post by:
Do you prefer malloc or calloc?
p = malloc(size);
Which of the following two is right to get same storage same as the
above call?
p = calloc(1, size);
p = calloc(size, 1);
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
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: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
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...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
