Skip site navigation (1)Skip section navigation (2)
Date:      08 Jul 1999 05:04:45 +0200
From:      Assar Westerlund <assar@sics.se>
To:        Dag-Erling Smorgrav <des@flood.ping.uio.no>
Cc:        Jamie Howard <howardjp@wam.umd.edu>, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org
Subject:   Re: Replacement for grep(1) (part 2)
Message-ID:  <5lemij265u.fsf@assaris.sics.se>
In-Reply-To: Dag-Erling Smorgrav's message of "07 Jul 1999 23:01:13 %2B0200"
References:  <Pine.GSO.4.10.9907052110250.13873-100000@uther.wam.umd.edu> <xzp7locthir.fsf@flood.ping.uio.no> <xzp1zektgp2.fsf@flood.ping.uio.no> <5laet8b2l8.fsf@assaris.sics.se> <xzpiu7wrx7q.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav <des@flood.ping.uio.no> writes:
> > And besides, I really don't think this is a grep function but actually
> > is useful for programs that don't have any strategy for handling out
> > of memory errors and might as well die (with a descriptive error
> > message, of course).  Let's call it emalloc and let's put in somewhere
> > where it can be used.
> 
> Too simple to warrant that, and other programs will likely want to
> handle the error differently.

I don't agree.

1. this is a small function, but it's useful in lots of programs
2. that helps lazy programmers write code that actually checks for
error returns instead of just ignoring them
3. it helps lots of programs that don't do anything intelligent (or
for which there isn't much bright things to do) when allocating memory
fails
4. having it in a library means it's more likely to be correct
(i.e. sz == 0)

but then again, I don't get to decide what goes in *BSD libc/libutil.
In my library there's already a emalloc, ecalloc, and erealloc.

/assar


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5lemij265u.fsf>