All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [TRIVIAL] kstrdup
Date: Mon, 13 Jan 2003 23:15:14 -0500	[thread overview]
Message-ID: <20030114041514.GA4844@gtf.org> (raw)
In-Reply-To: <200301140353.h0E3rWqZ004900@turing-police.cc.vt.edu>

On Mon, Jan 13, 2003 at 10:53:32PM -0500, Valdis.Kletnieks@vt.edu wrote:
> That's cool, long as everybody agrees on that - I've already filled my career
> quota of chasing down bugs due to non-threadsafe use of str*() functions. ;)

Don't worry, it's pretty much a rule in Linux, IMO.  Synchronization
belongs _above_ simple data type primitives like strings or lists.

That's why answering your email was quick and easy ;-)
The Linux answer is "don't do that" :)


> All the same, I'd probably feel better if it used strncpy() instead - there'd
> still be the possibility of copying now-stale data, but at least you'd not be
> able to walk off the end of the *new* array's allocated space....

_Not_ doing things like this is a reason why Linux is so fast in certain
areas :)  Linus preaches over and over, "do what you need to do, and no
more."

But having said that -- see my mail to Rusty about storing the strlen()
result and then calling memcpy().  It [purposefully] does not address
the fact that the string may become stale data, because it's the job of
a higher level to ensure that.  But it does make explicit a compiler
temporary, and allows us to use the presumeably-faster memcpy().

Not that kstrdup() matters a whole lot, but anyway...

	Jeff




  reply	other threads:[~2003-01-14  4:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-14  1:55 [PATCH] [TRIVIAL] kstrdup Rusty Russell
2003-01-14  3:19 ` Jeff Garzik
2003-01-15  6:45   ` Rusty Russell
2003-01-14  3:28 ` Valdis.Kletnieks
2003-01-14  3:38   ` Jeff Garzik
2003-01-14  3:53     ` Valdis.Kletnieks
2003-01-14  4:15       ` Jeff Garzik [this message]
2003-01-14  5:15         ` Valdis.Kletnieks
2003-01-14 11:48 ` Olaf Dietsche
2003-01-15  6:55   ` Rusty Russell
2003-01-19 23:37 ` Pavel Machek
2003-01-22  2:04   ` Rusty Russell
2003-01-23 14:02     ` Pavel Machek
2003-01-23 14:21       ` Martin Mares
2003-01-23 14:44         ` Pavel Machek
2003-01-29  4:51       ` Rusty Russell

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=20030114041514.GA4844@gtf.org \
    --to=jgarzik@pobox.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.