_strto[u]l() instead.
Furthermore, add parentheses after function names, as is standard in
kernel documentation.
Fixes: 4c925d6031f71 ("kstrto*: add documentation")
Signed-off-by: Kars Mulder
---
include/linux/kernel.h | 4 ++--
lib/kstrtox.c | 8
2 files changed
8b7b13 ("kernel.h: update comment about simple_strto()
functions")
Signed-off-by: Kars Mulder
---
include/linux/kernel.h | 4 ++--
lib/kstrtox.c | 12
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
On Thursday, July 02, 2020 09:55 CEST, David Laight wrote:
> Hmm... sscanf() is also horrid.
> Surprisingly difficult to use correctly.
>
> It is usually best to use strchr() (and maybe str[c]scn())
> to parse strings.
> For numbers use whatever the kernels current 'favourite' implementation
> of
> There ought to be one that returns a pointer to the first character
> that isn't converted - but I'm no expert on the full range of these
> functions.
I've searched for a function that parses an int from a string and
stores a pointer to the end; I can find some function simple_strtoul
that matc
On Saturday, July 04, 2020 16:39 CEST, Andy Shevchenko wrote:
> > I've searched for a function that parses an int from a string and
> > stores a pointer to the end; I can find some function simple_strtoul
> > that matches this criterion, but it's documented as
> >
> > "This function has caveat
On Wednesday, June 24, 2020 15:10 CEST, Greg Kroah-Hartman wrote:
> Have you hit any runtime issues with this code doing this? These
> strings should be held in writable memory, right? Or do you see a
> codepath where that is not the case?
I haven't ran into any issues with it; I was just looki
kstrdup() and letting
that copy be written to by strsep().
Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore")
Signed-off-by: Kars Mulder
---
drivers/usb/core/quirks.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers
kstrdup() and letting
that copy be written to by strsep().
Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore")
Signed-off-by: Kars Mulder
---
Changes v1 -> v2:
* Uses a different approach; now copies the value to the heap using
kstrdup() rather than co
In the file drivers/usb/core/quirks.c, I noticed a couple of odd things about
the function "quirks_param_set", and I'd like to check whether those are ok
according to the kernel programming practices. Here are the relevant lines from
the function (several lines omitted):
static int quir
On Saturday, July 04, 2020 22:54 CEST, Andy Shevchenko wrote:
> This and similar are not correct. 1/ They are not replacement per se
> (because of different behaviour). 2/ They simple_strto*() are not
> obsoleted.
>
> Can you correct all places you found and make it consistent?
Something like th
On Sunday, July 05, 2020 21:05 CEST, Andy Shevchenko
wrote:
> On Sunday, July 5, 2020, Kars Mulder wrote:
> > On Saturday, July 04, 2020 22:54 CEST, Andy Shevchenko wrote:
> > > This and similar are not correct. 1/ They are not replacement per se
> > > (because of di
On Sunday, July 05, 2020 21:11 CEST, Andy Shevchenko
wrote:
> On Sunday, July 5, 2020, Kars Mulder wrote:
> > On Saturday, July 04, 2020 22:54 CEST, Andy Shevchenko wrote:
> > > This and similar are not correct. 1/ They are not replacement per se
> > > (because of di
the stack and
letting that buffer be written to by strsep().
Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore")
Signed-off-by: Kars Mulder
---
drivers/usb/core/quirks.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers
On Monday, July 06, 2020 12:34 CEST, Greg Kroah-Hartman wrote:
> That's a lot of stack space, is it really needed? Can we just use a
> static variable instead, or dynamically allocate this?
It is very possible to statically or dynamically allocate this.
Statically reserving an additional 128 by
On Monday, July 06, 2020 15:07 CEST, Greg Kroah-Hartman wrote:
> Just test for memory allocation failure and handle it properly, it isn't
> hard to do.
>
> 128 bytes on the stack can be a problem, don't get in the habit of doing
> so please.
Thank you for the clarification. The next version of m
On Monday, September 21, 2020 13:30 CEST, Pavel Machek wrote:
> Simplify quirk handling.
This patch seems to contain two different "simplifications" in one.
I have no objections against the first simplification:
- if (quirk_list) {
- kfree(quirk_list);
- quirk_
On Saturday, June 27, 2020 12:24 CEST, David Laight wrote:
> The code quoted (using strset()) is almost certainly wrong.
> The caller is unlikely to expect the input be modified.
> Since it doesn't fault the string must be in read-write memory.
I tried writing a patch that avoids the writing-to-c
On Tuesday, June 23, 2020 21:55 CEST, Pavel Machek wrote:
> Odd, indeed... but not likely to cause immediate problems.
>
> You may want to cc relevant maintainers, or even run git
> blame and contact author.
Thank you for your response.
The code was written by Kai-Heng Feng, whom I shall CC. Th
18 matches
Mail list logo
