Date: Mon, 23 Jul 2001 03:07:02 +0100 From: Brian Somers <brian@Awfulhak.org> To: Assar Westerlund <assar@FreeBSD.org> Cc: Brian Somers <brian@Awfulhak.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@Awfulhak.org Subject: Re: cvs commit: src/lib/libutil ecalloc.c emalloc.3 emalloc.c erealloc.c estrdup.c Makefile libutil.h Message-ID: <200107230207.f6N272g13900@hak.lan.Awfulhak.org> In-Reply-To: Message from Assar Westerlund <assar@FreeBSD.org> of "23 Jul 2001 03:44:32 %2B0200." <5l4rs4h11b.fsf@assaris.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> Brian Somers <brian@Awfulhak.org> writes:
> > ptr = emalloc(n);
> >
> > will mean nothing to a regular C programmer (except that it's
> > probably doing a malloc with some extra stuff).
>
> Is it more obvious having xmalloc, xlmalloc, safe_malloc and all the
> other names that this function has been called in different programs?
Well, yes, if you can ``grep ^whatever *.c''.
> > if ((ptr = malloc(n)) == NULL) {
> > fprintf(stderr, "malloc %lu failed\n", (unsigned long)n);
> > exit(1);
> > }
> >
> > would actually be portable.
>
> Sure, and you would have 17 different versions of these, printing
> different messages and sometimes not bothering to check the return
> value at all.
Hmm, let's see. I'll take a look at the first program in the tree,
src/bin/cat/cat.c and find a similar scenario:
if (fclose(stdout))
err(1, "stdout");
In answer to your question, yes, in the same way that there are 1000s
of calls to fclose, some check the return, some don't. I don't want
them all changed to efclose() !
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.
> > 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.
> /assar
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
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?200107230207.f6N272g13900>