From owner-cvs-all Sun Jul 22 19:16:21 2001 Delivered-To: cvs-all@freebsd.org Received: from assaris.sics.se (dhcp114.iss.kth.se [130.237.7.114]) by hub.freebsd.org (Postfix) with ESMTP id 5F4DB37B401; Sun, 22 Jul 2001 19:16:14 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id EAA33371; Mon, 23 Jul 2001 04:16:31 +0200 (CEST) (envelope-from assar) To: Brian Somers Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libutil ecalloc.c emalloc.3 emalloc.c erealloc.c estrdup.c Makefile libutil.h References: <200107230207.f6N272g13900@hak.lan.Awfulhak.org> From: Assar Westerlund Date: 23 Jul 2001 04:16:29 +0200 In-Reply-To: Brian Somers's message of "Mon, 23 Jul 2001 03:07:02 +0100" Message-ID: <5lofqc9ypu.fsf@assaris.sics.se> Lines: 31 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brian Somers writes: > Well, yes, if you can ``grep ^whatever *.c''. And that is simpler than `man emalloc' ? > And before you argue against this specific example, my point is that > you could pick any group of functions from the standard libraries and > arbitrarily decide that an exit is frequently done afterwards, > therefore an e*() version of the function is required. I don't > believe that this approach is reasonable. But doing malloc (calloc, realloc), checking the return value and exiting if it fail is so common an idiom that it makes sense having that code in one function instead in lots of them all over the place. > > > Adding routines such as these to our libraries and then using them > > > from our programs just makes it irritating when you try to build > > > something on another OS -- not to mention obfuscating our code base. > > > > Just build an emalloc on that other OS. It's not a new problem. > > It's not a new problem, it's a portability problem that you're > magnifying. But there are two ways of attacking it: 1. write code that is so portabel that you can build it anywhere you might want to run it. 2. build wrapper libraries for what is needed to port your code. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message