If realloc() finds it necessary to move the memory block, then
does it free() the previously allocated block?
The C89 standard has some reference to undefined behaviour if one
realloc()'s memory that was freed by realloc(), but the only way
explicitly mentioned in the C89 standard to free memory via realloc()
is to realloc() it down to 0 bytes.
I had always assumed it would automatically free the previous memory,
but is the behaviour instead undefined [or defined as not happening] ?
--
"This was a Golden Age, a time of high adventure, rich living and
hard dying... but nobody thought so." -- Alfred Bester, TSMD
Nov 14 '05
86 4159
Robert Gamble wrote: On Fri, 20 May 2005 17:54:45 +0000, CBFalconer wrote: tigervamp wrote:
.... snip ... No, the behavior is well defined by the Standard, see section 7.20.3 of C99, I don't have a C89 copy handy.
No, I don't consider it well defined. It leaves too much up to the implementation in the case of zero block size requests.
I was referring specifically to the behavior of realloc deallocating the original object which is well defined.
This means that NULL is not always a sign of failure, and that a non-NULL return is not necessarily freeable or reallocable.
NULL is always a sign of failure when the size provided is non-zero, if you want to provide a size of zero is is easy enough to handle the return
What evidence do you have that a non-NULL value returned by realloc, when provided a size of zero, cannot safely be passed to free() or realloc()?
As I read the following from N869:
7.20.3 Memory management functions
[#1] The order and contiguity of storage allocated by
successive calls to the calloc, malloc, and realloc
functions is unspecified. The pointer returned if the
allocation succeeds is suitably aligned so that it may be
assigned to a pointer to any type of object and then used to
access such an object or an array of such objects in the
space allocated (until the space is explicitly freed or
reallocated). Each such allocation shall yield a pointer to
an object disjoint from any other object. The pointer
returned points to the start (lowest byte address) of the
allocated space. If the space cannot be allocated, a null
pointer is returned. If the size of the space requested is
zero, the behavior is implementation-defined: either a null
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^
pointer is returned, or the behavior is as if the size were
some nonzero value, except that the returned pointer shall
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^
not be used to access an object. The value of a pointer
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^
that refers to freed space is indeterminate.
Is freeing NULL so generated accessing an object? Is freeing
non-NULL so generated accessing an object? When things are buried
in layers of code we can easily guarantee that the pointer was
created by malloc/realloc, and we can even guard it by making it
NULL after passing to free, but that guard won't work if realloc
can return a non-freeable pointer.
--
Some informative links:
news:news.annou nce.newusers http://www.geocities.com/nnqweb/ http://www.catb.org/~esr/faqs/smart-questions.html http://www.caliburn.nl/topposting.html http://www.netmeister.org/news/learn2quote.html
CBFalconer <cb********@yah oo.com> wrote: Robert Gamble wrote: On Fri, 20 May 2005 17:54:45 +0000, CBFalconer wrote:
This means that NULL is not always a sign of failure, and that a non-NULL return is not necessarily freeable or reallocable.
I think you must be misreading something (or I don't understand
what your saying). I'm sure
free(malloc(0)) ;
is _always_ valid.
Have a look at the Rationale, page 160. If `calloc' returned
a non-reallocable pointer, then subsequent reallocations
could no work, could they?
[snip] What evidence do you have that a non-NULL value returned by realloc, when provided a size of zero, cannot safely be passed to free() or realloc()?
As I read the following from N869:
7.20.3 Memory management functions
[snip] pointer is returned. If the size of the space requested is zero, the behavior is implementation-defined: either a null
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^ not be used to access an object. The value of a pointer ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^ that refers to freed space is indeterminate.
Is freeing NULL so generated accessing an object?
Null ptrs are special cases. free(NULL) is no-op by definition.
Is freeing non-NULL so generated accessing an object?
No, because the Standard doesn't specify that `free' accesses
the object before deallocation.
I think that `malloc(0)' also allocates an object (if returns non-null),
which may be freed later. The compiler knows the object won't be
accessed, therefore the returned pointer may "point" into some
read-only memory, or may have some invalid/trap value which blows up
when dereferenced.
CBFalconer <cb********@yah oo.com> wrote earlier:
In my nmalloc implementation for DJGPP I have chosen to treat a zero block size as a request for one byte, and let the alignment mechanisms raise it as they will.
I'm not criticizing this, there're good reasons to do it like that,
but the Standard does not require the allocated object to have
alignment more than its size, right? Subsequent `malloc(1)'-s could
return ptrs that differ by 1 byte, right? (I'm asking because
the Std is a bit unclear there, IMHO.)
--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
"S.Tobias" wrote: CBFalconer <cb********@yah oo.com> wrote earlier:
In my nmalloc implementation for DJGPP I have chosen to treat a zero block size as a request for one byte, and let the alignment mechanisms raise it as they will.
I'm not criticizing this, there're good reasons to do it like that, but the Standard does not require the allocated object to have alignment more than its size, right? Subsequent `malloc(1)'-s could return ptrs that differ by 1 byte, right? (I'm asking because the Std is a bit unclear there, IMHO.)
No, that can't happen. Any non NULL return from
malloc/calloc/realloc must be suitably aligned for any object
whatsoever.
--
Some informative links:
news:news.annou nce.newusers http://www.geocities.com/nnqweb/ http://www.catb.org/~esr/faqs/smart-questions.html http://www.caliburn.nl/topposting.html http://www.netmeister.org/news/learn2quote.html
On Sat, 21 May 2005 05:23:39 +0000, CBFalconer wrote: Robert Gamble wrote: On Fri, 20 May 2005 17:54:45 +0000, CBFalconer wrote: tigervamp wrote: ... snip ... No, the behavior is well defined by the Standard, see section 7.20.3 of C99, I don't have a C89 copy handy.
No, I don't consider it well defined. It leaves too much up to the implementation in the case of zero block size requests. I was referring specifically to the behavior of realloc deallocating the original object which is well defined.
This means that NULL is not always a sign of failure, and that a non-NULL return is not necessarily freeable or reallocable.
NULL is always a sign of failure when the size provided is non-zero, if you want to provide a size of zero is is easy enough to handle the return
What evidence do you have that a non-NULL value returned by realloc, when provided a size of zero, cannot safely be passed to free() or realloc()?
As I read the following from N869:
7.20.3 Memory management functions
[#1] The order and contiguity of storage allocated by successive calls to the calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly freed or reallocated). Each such allocation shall yield a pointer to an object disjoint from any other object. The pointer returned points to the start (lowest byte address) of the allocated space. If the space cannot be allocated, a null pointer is returned. If the size of the space requested is zero, the behavior is implementation-defined: either a null
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^ not be used to access an object. The value of a pointer ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^ that refers to freed space is indeterminate.
Is freeing NULL so generated accessing an object?
No.
Is freeing non-NULL so generated accessing an object?
No.
When things are buried in layers of code we can easily guarantee that the pointer was created by malloc/realloc, and we can even guard it by making it NULL after passing to free, but that guard won't work if realloc can return a non-freeable pointer.
The pointer returned by calloc/malloc/realloc in any scenerio can always
be passed to free() at least once (only once for non-NULL).
From 7.20.3.2p2, free description:
"The free function causes the space pointed to by ptr to be deallocated,
that is, made available for further allocation. If ptr is a null pointer,
no action occurs. Otherwise, if the argument does not match a pointer
earlier returned by the calloc, malloc, or realloc function, or if the
space has been deallocated by a call to free or realloc, the behavior is
undefined."
According to the description, any pointer returned by calloc, malloc or
realloc that has not already been freed may be passed to free() without
invoking undefined behavior. No special provisions are made for the case
where zero size was passed to the allocation function to generate the
pointer in question.
To further support this position, section 7.20.3 of the Rationale
v5.10 provides the following example:
"The treatment of null pointers and zero-length allocation requests in the
definition of these functions was in part guided by a desire to support
this paradigm:
OBJ * p; // pointer to a variable list of OBJs
/* initial allocation */
p = (OBJ *) calloc(0, sizeof(OBJ));
/* ... */
/* reallocations until size settles */
while(1) {
p = (OBJ *) realloc((void *)p, c * sizeof(OBJ));
/* change value of c or break out of loop */
}
"
In this example, p is assigned the return value of calloc which, since one
of the arguments is zero, according to Standard behaves the same as if
malloc were passed a size of zero. p is now either NULL, or non-NULL
depending on the implementation (or possibly NULL if an error occured).
The value of p is then passed to realloc to increase the size, initially
from zero. If p was NULL from the calloc call, realloc will behave like
malloc. If calloc returned non-NULL, that value is now being passed to
realloc which deallocates the original zero-length object (as free would
do) and allocates more memory, etc.
In short, if an implmentation can "allocate" zero-length objects, it can
also free/realloc them. The effort needed to handle the implementation
defined part seems minimal.
Rob Gamble
CBFalconer wrote: "S.Tobias" wrote:
CBFalconer <cb********@yah oo.com> wrote earlier:
In my nmalloc implementation for DJGPP I have chosen to treat a zero block size as a request for one byte, and let the alignment mechanisms raise it as they will.
I'm not criticizing this, there're good reasons to do it like that, but the Standard does not require the allocated object to have alignment more than its size, right? Subsequent `malloc(1)'-s could return ptrs that differ by 1 byte, right? (I'm asking because the Std is a bit unclear there, IMHO.)
No, that can't happen. Any non NULL return from malloc/calloc/realloc must be suitably aligned for any object whatsoever.
Can you provide chapter and verse, please?
This seems to be an unnecessary restriction -- why should malloc()
return 16-byte aligned memory for a 3-byte request if the
implementation "knows" that this implies a necessity for, say,
2-byte alignment _at_most_?
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
CBFalconer wrote: "S.Tobias" wrote:
CBFalconer <cb********@yah oo.com> wrote earlier:
In my nmalloc implementation for DJGPP I have chosen to treat a zero block size as a request for one byte, and let the alignment mechanisms raise it as they will.
I'm not criticizing this, there're good reasons to do it like that, but the Standard does not require the allocated object to have alignment more than its size, right? Subsequent `malloc(1)'-s could return ptrs that differ by 1 byte, right? (I'm asking because the Std is a bit unclear there, IMHO.)
No, that can't happen. Any non NULL return from malloc/calloc/realloc must be suitably aligned for any object whatsoever.
I'm writing a malloc thing and compiling it in gcc on a pc.
How do you know what the alignment should be?
On Sat, 21 May 2005 16:38:51 +0200, Michael Mair wrote: CBFalconer wrote: "S.Tobias" wrote:
CBFalconer <cb********@yah oo.com> wrote earlier:
In my nmalloc implementation for DJGPP I have chosen to treat a zero block size as a request for one byte, and let the alignment mechanisms raise it as they will.
I'm not criticizing this, there're good reasons to do it like that, but the Standard does not require the allocated object to have alignment more than its size, right? Subsequent `malloc(1)'-s could return ptrs that differ by 1 byte, right? (I'm asking because the Std is a bit unclear there, IMHO.) No, that can't happen. Any non NULL return from malloc/calloc/realloc must be suitably aligned for any object whatsoever.
Can you provide chapter and verse, please?
7.20.3p1 sentence 2:
"The pointer returned if the allocation succeeds is suitably aligned so
that it may be assigned to a pointer to any type of object and then used
to access such an object or an array of such objects in the space
allocated (until the space is explicitly deallocated)."
This seems to be an unnecessary restriction -- why should malloc() return 16-byte aligned memory for a 3-byte request if the implementation "knows" that this implies a necessity for, say, 2-byte alignment _at_most_?
I'm not sure why, the Rationale doesn't give any hints here. It doesn't
particularly make sense that the allocated space must be aligned to
store an object that could not fit into the space, perhaps there is
another reason we are overlooking or maybe I'm misinterpreting the above
quote.
Cheers Michael
Rob Gamble
Robert Gamble <rg*******@gmai l.com> wrote: On Sat, 21 May 2005 16:38:51 +0200, Michael Mair wrote: CBFalconer wrote: "S.Tobias" wrote:
the Standard does not require the allocated object to have alignment more than its size, right? Subsequent `malloc(1)'-s could return ptrs that differ by 1 byte, right? (I'm asking because the Std is a bit unclear there, IMHO.)
No, that can't happen. Any non NULL return from malloc/calloc/realloc must be suitably aligned for any object whatsoever. Can you provide chapter and verse, please?
7.20.3p1 sentence 2:
"The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated)."
My interpretation of this is that the word "object" refers to
the allocated object, and "any type of object" means any type
that *this* object can have, although I think it is very unclear.
Without such interpretation the second part of the sentence
would not make sense (unless we accept that malloc(1) returns
an object suitable for any type - SIZE_MAX bytes at least).
--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
In article <1d************ @main.anatron.c om.au>,
Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> wrote: I'm writing a malloc thing and compiling it in gcc on a pc. How do you know what the alignment should be?
Compiler magic.
(This is something that the implementation needs to know (not just
for malloc; it will be needed anywhere it creates an object that may
have alignment restrictions), but it's not exposed to the programmer,
at least not without going beyond what the standard defines.)
dave
--
Dave Vandervies dj******@csclub .uwaterloo.ca
Google seems to think that "united kingdom" should be under the category
of "Mature Content". this doesn't reflect well on either Google or the UK,
though i'm not sure which --Mike Burrell in comp.lang.c
>CBFalconer wrote: ... Any non NULL return from malloc/calloc/realloc must be suitably aligned for any object whatsoever.
In article <3f************ @individual.net >
Michael Mair <Mi**********@i nvalid.invalid> wrote:Can you provide chapter and verse, please? This seems to be an unnecessary restriction -- why should malloc() return 16-byte aligned memory for a 3-byte request if the implementati on "knows" that this implies a necessity for, say, 2-byte alignment _at_most_?
Indeed, it does seem unnecessary. It also seems to be what the
Standard requires. I suspect, however, that an implementor might
be able to get away with the "as-if" rule and align to just 2 bytes
in this case, provided the following code fragment still works:
void *vp;
char *cp;
double *dp;
/* add other types if desired */
cp = malloc(3);
if (cp == NULL) ... handle error ...
vp = cp;
dp = vp;
assert(vp == cp);
assert(dp == vp);
cp = (char *)dp;
assert(cp == vp);
puts("all OK");
In other words, if we have a system on which we can detect "failure
to align for any object whatsoever" by just using ordinary pointer
assignments, *then* that system will have to do 16-byte (or whatever)
alignment for a 3-byte malloc; but if the system handles "misaligned "
pointers without trouble, as long as they are not used to access
their misaligned objects, then -- because there will be no way for
the user to tell -- the as-if rule will allow us to implement
malloc(3) with just two-byte alignment.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Deephay |
last post by:
Greetings all,
I have a program that used the realloc() function to change the
allocated size of a buffer, the program works with some arguments, but
with some other arguments, it will show me the error message like:
*** glibc detected *** realloc(): invalid next size: 0x0804c3a8 ***
and then I inserted a perror("realloc") to see what happend, it says that:
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
| |
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 Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
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 protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |