From owner-freebsd-hackers Thu Aug 20 11:42:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28996 for freebsd-hackers-outgoing; Thu, 20 Aug 1998 11:42:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28991 for ; Thu, 20 Aug 1998 11:42:46 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id LAA25426; Thu, 20 Aug 1998 11:42:02 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) cc: Warner Losh , hackers@FreeBSD.ORG Subject: Re: Realloc fix for review In-reply-to: Your message of "20 Aug 1998 16:48:46 -0000." Date: Thu, 20 Aug 1998 11:42:02 -0700 Message-ID: <25422.903638522@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is that really a good idea? If you free the old block when realloc() > fails, you lose whatever data was in it (and therefore potentially > lose the ability to generate a sensible error message or recover > gracefully). Such a change should be done on a per-case basis, rather > than blindly applied to every snippet that calls realloc(). Hmmm. In my previous message, I'd also assumed that Warner was only talking about changing instances of realloc() where the application very definitely wanted the free-on-failure behavior. Replacing every instance of realloc() with the new call would, indeed, be evil incarnate given realloc()'s well-documented "I don't fondle the previous value on failure" behavior. Heck, I thought that was the entire reason for a new call in the first place. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message