jfh@rpp386.cactus.org (John F. Haugh II) (10/10/89)
In article <11234@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >NO NO NO. You have mispresented the argument. So long as malloc() >(assumed to be properly declared!) doesn't return a null pointer, >the above will work in ALL conforming implementations. The trouble >arises only when after the free() the pointer p (NOT what it points >to, that's inarguably invalid) continues to be examined or otherwise >manipulated by the program. I only bring this up because I've been asleep ... Doesn't free() insure the pointer remains valid until the next call to malloc(). This seems to be implied by the statement that realloc() works if the pointer was used as an argument since the last call to malloc(). This would seem to imply that for this to work, the pointer passed to free -must- remain valid. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of MACH is ... InterNet: jfh@rpp386.cactus.org | ... Messages Are Crufty Hacks. UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
henry@utzoo.uucp (Henry Spencer) (10/11/89)
In article <17119@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >Doesn't free() insure the pointer remains valid until the next >call to malloc()... No. Some Unix implementations guaranteed this; ANSI C does not. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/11/89)
In article <17119@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >Doesn't free() insure the pointer remains valid until the next >call to malloc(). No. The "guarantee" you cited was repealed long ago. A free()d pointer is immediately "dead".