schmidt@indetech.com (Doug Schmidt) (07/04/90)
Hi,
Several months ago there was a big discussion on comp.lang.c
about the legality/portability of the following sort of code:
----------------------------------------
void
foo (n)
int n;
{
char *malloc ();
char *s = malloc (n);
/* ... */
free (s);
s = 0; /* Is this assignment always legal? */
/* ... */
}
----------------------------------------
I seem to recall there was a problem with the assignment to
char *s *after* the free. Can someone please refresh my memory
as to what the problem was, and why it is a problem? Would
replacing s = 0 by s = malloc (n) have the same problem?
thanks,
Doug
--
____*_ Douglas C. Schmidt schmidt@indetech.com
\ / / Independence Technologies {sun,sharkey,pacbell}!indetech!schmidt
\/ / 42705 Lawrence Place FAX: 415 438-2034
\/ Fremont, CA 94538 Voice: 415 438-2023cpcahil@virtech.uucp (Conor P. Cahill) (07/04/90)
In article <1990Jul3.185032.8434@indetech.com> schmidt@indetech.UUCP (Doug Schmidt) writes: > char *s = malloc (n); > /* ... */ > free (s); > s = 0; /* Is this assignment always legal? */ > > I seem to recall there was a problem with the assignment to >char *s *after* the free. Can someone please refresh my memory >as to what the problem was, and why it is a problem? Would >replacing s = 0 by s = malloc (n) have the same problem? There is no problem with s = 0. However on some "hypothetical" systems, the line: if( s == 0 ) can cause the program to die, since you are causing an illegal pointer to be loaded into an address register. I don't know of any current machine where that will happen, but it could be the case on some system in the future. What *almost* guarrantees that it won't cause the program to die is the fact that on most, if not all, implementations free() does not actually return space to the OS. If you want to be safe an absolute 100% of the time, don't use a freed pointer (including dereferencing, or comparing). If 99.99999% saftey is ok, then just be sure to not dereference it. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
edward@runxtsa.runx.oz.au (Edward Birch) (07/11/90)
> In article <1990Jul3.185032.8434@indetech.com> > schmidt@indetech.UUCP (Doug Schmidt) writes: > > char *s = malloc (n); > > /* ... */ > > free (s); > > s = 0; /* Is this assignment always legal? */ > > I quote the manual here: The argument to "free" is a pointer to a block previosly allocated by "malloc"; after "free" is performed this space is made available for further allocation, but its contents are left undisturbed. The above manual entry implies that the following is correct although *strongly* unadvisible. char * ptr = malloc(5); /* assume malloc doesn't fail */ /* .... */ ptr[0] = 10; free(ptr); printf("It's ok to access data after a call to free %d\n", ptr[0]); While the above may be ok for a programmer who really think's he/she knows what they are doing. I strongly suspect that it will cause problems when porting to other operating systems or when being maintained by other programmers. An assignment of "ptr = 0;" in the above example after the "free(ptr);" will stop accesses of the pointer from that point on by causing a core dump (on unix) you won't be nearly so lucky on ms-dos or like systems. This will aid testing & debugging of the program. In conclusion the assignment of "s = 0;" is always valid. Edward Birch UUCP: seismo!munnari!runx.oz!edward ACSnet: edward@runx.oz ARPA: edward%runx.oz@seismo.css.gov CSNET: edward@runx.oz
davidsen@antarctica.crd.GE.COM (william E Davidsen) (07/12/90)
In article <1956@runxtsa.runx.oz.au>, edward@runxtsa.runx.oz.au (Edward Birch) writes: |> I quote the manual here: |> The argument to "free" is a pointer to a block previosly allocated |> by "malloc"; after "free" is performed this space is made available |> for further allocation, but its contents are left undisturbed. I'm not sure what manual you think is "the" manual, K&R 2nd ed. doesn't say that (pg 252), nor does my copy (admiditedly a draft copy) of the ANSI standard. What athority are you quoting? This sounds like some vendor nonportability from an early UNIX version.
akira@atson.asahi-np.co.jp (Akira Takiguchi) (07/12/90)
In article <1956@runxtsa.runx.oz.au> edward@runxtsa.runx.oz.au (Edward Birch) writes: |I quote the manual here: | The argument to "free" is a pointer to a block previosly allocated | by "malloc"; after "free" is performed this space is made available | for further allocation, but its contents are left undisturbed. | |The above manual entry implies that the following is correct although |*strongly* unadvisible. It seems to me that the manual warns about the possibility of a security breach when you leave sensitive data in the free'ed space. -- Akira Takiguchi @ ATSON, Inc.
steve@taumet.com (Stephen Clamage) (07/13/90)
edward@runxtsa.runx.oz.au (Edward Birch) writes: >I quote the manual here: > The argument to "free" is a pointer to a block previosly allocated > by "malloc"; after "free" is performed this space is made available > for further allocation, but its contents are left undisturbed. I wonder which manual that is. ANSI C makes no such guarantee. See section 4.10.3 of the standard. As Mr Birch also pointed out, if you play games with malloc/free, don't expect your whiz-bang code to run on another system. -- Steve Clamage, TauMetric Corp, steve@taumet.com
skwu@spot.Colorado.EDU (WU SHI-KUEI) (07/14/90)
>>I quote the manual here: >> The argument to "free" is a pointer to a block previosly allocated >> by "malloc"; after "free" is performed this space is made available >> for further allocation, but its contents are left undisturbed. > >I wonder which manual that is. The AT&T System V.3 Programmer Manual for the 3B2.