From: Dan Aloni <da-x@gmx.net>
To: J?rn Engel <joern@wohnheim.fh-wedel.de>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [BK PATCH] One strdup() to rule them all
Date: Mon, 25 Aug 2003 19:55:12 +0300 [thread overview]
Message-ID: <20030825165512.GA9782@callisto.yi.org> (raw)
In-Reply-To: <20030825163745.GA17608@wohnheim.fh-wedel.de>
On Mon, Aug 25, 2003 at 06:37:45PM +0200, J?rn Engel wrote:
> > +/**
> > + * strdup - Allocate a copy of a string.
> > + * @s: The string to copy. Must not be NULL.
> > + *
> > + * returns the address of the allocation, or NULL on
> > + * error.
> > + */
> > +char *strdup(const char *s)
> > +{
> > + char *rv = kmalloc(strlen(s)+1, GFP_KERNEL);
> > + if (rv)
> > + strcpy(rv, s);
> > + return rv;
> > +}
>
> My gut feeling is always afraid when something "must not be NULL",
> someone will ignore this and Bad Things (tm) happen. Is strdup ever
> used such performance critical code that the extra check would hurt?
There are two reasons while it shouldn't have a NULL check. One,
persistency: the other str*() functions don't do this sort of check.
Two, for general uses like that:
new_name = strdup(name);
if (!new_name)
goto allocation_failed;
With this check, NULL would be returning from strdup() either because
name == NULL or when the allocation fails. You cannot simply pass that
information through its return value and the caller would need to
check whether name == NULL by itself which should have been done anyway.
Passing NULL to strdup() is a bug, which would have NOT show as an
Oops if you add this check, and that is bad. Maybe it would be worth
to add a BUG_ON(s == NULL) instead, and perhaps also add this to the
other str*() functions, but that is a different patch.
--
Dan Aloni
da-x@gmx.net
next prev parent reply other threads:[~2003-08-25 16:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-25 16:14 [BK PATCH] One strdup() to rule them all Dan Aloni
2003-08-25 16:25 ` Jakub Jelinek
2003-08-25 16:34 ` Dan Aloni
2003-08-25 17:05 ` Jeff Garzik
2003-08-25 17:23 ` Dan Aloni
2003-08-25 17:49 ` Andries Brouwer
2003-09-11 16:22 ` Jörn Engel
2003-09-12 1:57 ` Rusty Russell
2003-09-12 3:12 ` Jeff Garzik
2003-09-12 4:16 ` Rusty Russell
2003-09-12 8:49 ` Bernd Petrovitsch
2003-08-25 16:37 ` Jörn Engel
2003-08-25 16:55 ` Dan Aloni [this message]
2003-08-25 17:02 ` Jörn Engel
2003-08-25 17:04 ` Jeff Garzik
2003-08-25 17:08 ` Jörn Engel
2003-08-25 17:22 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030825165512.GA9782@callisto.yi.org \
--to=da-x@gmx.net \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox