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
On Wed, Apr 29, 2015 at 2:35 AM, Al Viro v...@zeniv.linux.org.uk 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
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
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
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
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
> 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
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
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
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
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 optimizing
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
as a
On 28 April 2015 at 18:05 Al Viro v...@zeniv.linux.org.uk 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.
On Tue, Apr 28, 2015 at 9:05 AM, Al Viro v...@zeniv.linux.org.uk 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
On 28 April 2015 at 19:39 Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Apr 28, 2015 at 06:42:10PM +0200, Fabian Frederick wrote:
On 28 April 2015 at 18:05 Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Apr 28, 2015 at 07:35:10AM +0200, Fabian Frederick wrote:
Al,
On Tue, Apr 28, 2015 at 2:38 PM, Chris Metcalf cmetc...@ezchip.com 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
On Tue, Apr 28, 2015 at 12:48 PM, Chris Metcalf cmetc...@ezchip.com 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
On 04/28/2015 04:51 PM, Linus Torvalds wrote:
On Tue, Apr 28, 2015 at 12:48 PM, Chris Metcalf cmetc...@ezchip.com 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
On Tue, Apr 28, 2015 at 06:42:10PM +0200, Fabian Frederick wrote:
On 28 April 2015 at 18:05 Al Viro v...@zeniv.linux.org.uk 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 04/28/2015 12:42 PM, Linus Torvalds wrote:
On Tue, Apr 28, 2015 at 9:05 AM, Al Viro v...@zeniv.linux.org.uk 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
> 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
>
>
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
replaces perfectly safe code with undefined behaviour. All in the
commit 39d7a29f867bd5a4a551fad6bb3812ceddb0bce1
Author: Fabian Frederick f...@skynet.be
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
replaces perfectly safe code with undefined behaviour.
On 28 April 2015 at 05:48 Al Viro v...@zeniv.linux.org.uk wrote:
commit 39d7a29f867bd5a4a551fad6bb3812ceddb0bce1
Author: Fabian Frederick f...@skynet.be
Date: Fri Jun 6 14:36:15 2014 -0700
fs/befs/linuxvfs.c: replace strncpy by strlcpy
strncpy + end of string assignment
26 matches
Mail list logo
