Date: 23 Jul 2001 04:16:29 +0200 From: Assar Westerlund <assar@FreeBSD.org> To: Brian Somers <brian@Awfulhak.org> 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 Message-ID: <5lofqc9ypu.fsf@assaris.sics.se> In-Reply-To: Brian Somers's message of "Mon, 23 Jul 2001 03:07:02 %2B0100" References: <200107230207.f6N272g13900@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Somers <brian@Awfulhak.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5lofqc9ypu.fsf>