On Wed, Apr 29, 2015 at 2:35 AM, Al Viro wrote:
> strncpy() has another use, though, and it can't be replaced by strlcpy() -
> see the commits that had started this thread. IMO they (and anything
> else of the same nature) really need to be reverted; using strlcpy() on
> something that isn't guar
On Tue, Apr 28, 2015 at 02:48:45PM -0700, Linus Torvalds wrote:
> I suspect you could take that lib/strncpy_from_user.c and massage it
> reasonably trivially to be a good function.
>
> That said, I can't think of a single strncpy (or strlcpy) in kernel
> space that is actually worth even optimizi
On Tue, Apr 28, 2015 at 2:38 PM, Chris Metcalf wrote:
>
> To do that we'd probably want to provide a generic version that
> just copied byte-by-byte, and encourage architecture variants
> that were more efficient.
Our generic "strncpy_from_user()" is actually fairly efficient, and
reasonably port
On 04/28/2015 04:51 PM, Linus Torvalds wrote:
On Tue, Apr 28, 2015 at 12:48 PM, Chris Metcalf wrote:
FWIW, I wanted to deal with some strncpy/strlcpy API issues last year
and just put a "strscpy()" function in arch/tile/gxio/mpipe.c,
So quite frankly, I don't like that one either.
Some people
On Tue, Apr 28, 2015 at 12:48 PM, Chris Metcalf wrote:
>
> FWIW, I wanted to deal with some strncpy/strlcpy API issues last year
> and just put a "strscpy()" function in arch/tile/gxio/mpipe.c,
So quite frankly, I don't like that one either.
Some people really *do* want truncation, and your strs
> On 28 April 2015 at 19:39 Al Viro wrote:
>
>
> On Tue, Apr 28, 2015 at 06:42:10PM +0200, Fabian Frederick wrote:
> >
> >
> > > On 28 April 2015 at 18:05 Al Viro wrote:
> > >
> > >
> > > On Tue, Apr 28, 2015 at 07:35:10AM +0200, Fabian Frederick wrote:
> > >
> > > > > Al, very unhappy about th
On 04/28/2015 12:42 PM, Linus Torvalds wrote:
On Tue, Apr 28, 2015 at 9:05 AM, Al Viro wrote:
Unfortunately, we _can't_ make strlcpy() never look past src + size - 1 -
not without changing its semantics.
Yeah, strlcpy is actually nasty. I don't understand why people like it
so much. It's a c
On Tue, Apr 28, 2015 at 06:42:10PM +0200, Fabian Frederick wrote:
>
>
> > On 28 April 2015 at 18:05 Al Viro wrote:
> >
> >
> > On Tue, Apr 28, 2015 at 07:35:10AM +0200, Fabian Frederick wrote:
> >
> > > > Al, very unhappy about the prospect of looking through ~2000 calls of
> > > > strlcpy()
> >
On Tue, Apr 28, 2015 at 9:05 AM, Al Viro wrote:
>
> Unfortunately, we _can't_ make strlcpy() never look past src + size - 1 -
> not without changing its semantics.
Yeah, strlcpy is actually nasty. I don't understand why people like it
so much. It's a crap interface, and completely unsuitable for
> On 28 April 2015 at 18:05 Al Viro wrote:
>
>
> On Tue, Apr 28, 2015 at 07:35:10AM +0200, Fabian Frederick wrote:
>
> > > Al, very unhappy about the prospect of looking through ~2000 calls of
> > > strlcpy()
> > > we have in the tree...
> >
> > Sorry Al, I thought it was more secure.
>
> It's n
On Tue, Apr 28, 2015 at 07:35:10AM +0200, Fabian Frederick wrote:
> > Al, very unhappy about the prospect of looking through ~2000 calls of
> > strlcpy()
> > we have in the tree...
>
> Sorry Al, I thought it was more secure.
It's not just you, unfortunately, and dumping all that annoyance on you
> On 28 April 2015 at 05:48 Al Viro wrote:
>
>
> commit 39d7a29f867bd5a4a551fad6bb3812ceddb0bce1
> Author: Fabian Frederick
> Date: Fri Jun 6 14:36:15 2014 -0700
>
> fs/befs/linuxvfs.c: replace strncpy by strlcpy
>
> strncpy + end of string assignment replaced by strlcpy
>
> repl
12 matches
Mail list logo