> Thought that I was still fairly clear, or that I just assumed that
> everyone was more or less familiar with the problems between strncpy
> strlcpy etc.
> Did not think all that should be includerad in chang log.
I don't think you need to write a novel.
So the basic issue is that you're not
2014-09-24 23:26 GMT+02:00 Andrew Morton :
> On Wed, 24 Sep 2014 22:51:14 +0200 Rickard Strandqvist
> wrote:
>
>> 2014-09-24 17:41 GMT+02:00 Dan Carpenter :
>> > On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen wrote:
>> >> On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
>> >>
On Wed, 24 Sep 2014 22:51:14 +0200 Rickard Strandqvist
wrote:
> 2014-09-24 17:41 GMT+02:00 Dan Carpenter :
> > On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen wrote:
> >> On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
> >> > On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi
2014-09-24 17:41 GMT+02:00 Dan Carpenter :
> On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen wrote:
>> On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
>> > On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
>> > > On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard
On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen wrote:
> On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
> > On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
> > > On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
> > > > Added a function strzcpy
> I can show a large amount of patches that show that many people do not
> seem aware that strncpy does not guarantee a terminating null character.
> Add to that all the code I've seen like this:
Yes that's understood.
The question was: where do we rely on the padding semantics of strncpy?
On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
> On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
> > On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
> > > Added a function strzcpy which works the same as strncpy,
> > > but guaranteed to produce the
On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
> On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
> > Do we really need the bizarre strncpy padding semantics for anything?
> > Why not just use strlcpy?
>
> We do need the padding in many places to prevent information
On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
> On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
> > Added a function strzcpy which works the same as strncpy,
> > but guaranteed to produce the trailing null character.
>
> Do we really need the bizarre strncpy
On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
Added a function strzcpy which works the same as strncpy,
but guaranteed to produce the trailing null character.
Do we really need the bizarre strncpy padding
On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
Do we really need the bizarre strncpy padding semantics for anything?
Why not just use strlcpy?
We do need the padding in many places to prevent information leaks.
On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
Added a function strzcpy which works the same as strncpy,
but guaranteed to produce the trailing
I can show a large amount of patches that show that many people do not
seem aware that strncpy does not guarantee a terminating null character.
Add to that all the code I've seen like this:
Yes that's understood.
The question was: where do we rely on the padding semantics of strncpy?
-Andi
On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen wrote:
On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
Added a function strzcpy which works
2014-09-24 17:41 GMT+02:00 Dan Carpenter dan.carpen...@oracle.com:
On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen wrote:
On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
On Tue, Sep 23, 2014 at 06:17:53PM -0700, Andi Kleen wrote:
On Wed, Sep 24, 2014 at 12:13:36AM +0200,
On Wed, 24 Sep 2014 22:51:14 +0200 Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
2014-09-24 17:41 GMT+02:00 Dan Carpenter dan.carpen...@oracle.com:
On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen wrote:
On Wed, Sep 24, 2014 at 10:52:06AM +0300, Dan Carpenter wrote:
2014-09-24 23:26 GMT+02:00 Andrew Morton a...@linux-foundation.org:
On Wed, 24 Sep 2014 22:51:14 +0200 Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
2014-09-24 17:41 GMT+02:00 Dan Carpenter dan.carpen...@oracle.com:
On Wed, Sep 24, 2014 at 07:35:55AM -0700, Andi Kleen
Thought that I was still fairly clear, or that I just assumed that
everyone was more or less familiar with the problems between strncpy
strlcpy etc.
Did not think all that should be includerad in chang log.
I don't think you need to write a novel.
So the basic issue is that you're not sure
On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
> Added a function strzcpy which works the same as strncpy,
> but guaranteed to produce the trailing null character.
Do we really need the bizarre strncpy padding semantics for anything?
Why not just use strlcpy?
-Andi
--
To
On Wed, 24 Sep 2014 00:13:36 +0200 Rickard Strandqvist
wrote:
> +/**
> + * strzcpy - Copy a length-limited, C-string
> + * @dest: Where to copy the string to
> + * @src: Where to copy the string from
> + * @count: The maximum number of bytes to copy
> + *
> + * The result is %NUL-terminated,
>
I've added a feature strzcpy to make it easier to not do wrong
when you use the function strncpy.
By not have to add a guaranteed trailing null character:
strncpy(to, src, c);
to[c - 1] = '\0';
This arose after a discussion with Dan Carpenter:
https://lkml.org/lkml/2014/9/15/74
And I was
Added a function strzcpy which works the same as strncpy,
but guaranteed to produce the trailing null character.
Signed-off-by: Rickard Strandqvist
---
include/linux/string.h |1 +
lib/string.c | 31 +++
2 files changed, 32 insertions(+)
diff --git
I've added a feature strzcpy to make it easier to not do wrong
when you use the function strncpy.
By not have to add a guaranteed trailing null character:
strncpy(to, src, c);
to[c - 1] = '\0';
This arose after a discussion with Dan Carpenter:
https://lkml.org/lkml/2014/9/15/74
And I was
Added a function strzcpy which works the same as strncpy,
but guaranteed to produce the trailing null character.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
include/linux/string.h |1 +
lib/string.c | 31 +++
2 files
On Wed, 24 Sep 2014 00:13:36 +0200 Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
+/**
+ * strzcpy - Copy a length-limited, C-string
+ * @dest: Where to copy the string to
+ * @src: Where to copy the string from
+ * @count: The maximum number of bytes to copy
+ *
+ *
On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
Added a function strzcpy which works the same as strncpy,
but guaranteed to produce the trailing null character.
Do we really need the bizarre strncpy padding semantics for anything?
Why not just use strlcpy?
-Andi
--
To
26 matches
Mail list logo
