Fix two problems found in the strrchr() implementation for s390
architectures: evaluate empty strings (return the string address instead of
NULL, if '\0' is passed as second argument); evaluate the first character
of non-empty strings (the current implementation stops at the second).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: [email protected]
Reported-by: Heiko Carstens <[email protected]> (incorrect behavior with empty strings)
Signed-off-by: Roberto Sassu <[email protected]>
---
arch/s390/lib/string.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/s390/lib/string.c b/arch/s390/lib/string.c
index cfcdf76d6a95..8127e110d154 100644
--- a/arch/s390/lib/string.c
+++ b/arch/s390/lib/string.c
@@ -259,14 +259,13 @@ EXPORT_SYMBOL(strcmp);
#ifdef __HAVE_ARCH_STRRCHR
char *strrchr(const char *s, int c)
{
- size_t len = __strend(s) - s;
-
- if (len)
- do {
- if (s[len] == (char) c)
- return (char *) s + len;
- } while (--len > 0);
- return NULL;
+ size_t len = __strend(s) - s;
+
+ do {
+ if (s[len] == (char) c)
+ return (char *) s + len;
+ } while (--len >= 0);
+ return NULL;
}
EXPORT_SYMBOL(strrchr);
#endif
--
2.32.0
On Tue, Oct 05, 2021 at 02:08:36PM +0200, Roberto Sassu wrote:
> Fix two problems found in the strrchr() implementation for s390
> architectures: evaluate empty strings (return the string address instead of
> NULL, if '\0' is passed as second argument); evaluate the first character
> of non-empty strings (the current implementation stops at the second).
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: [email protected]
> Reported-by: Heiko Carstens <[email protected]> (incorrect behavior with empty strings)
> Signed-off-by: Roberto Sassu <[email protected]>
> ---
> arch/s390/lib/string.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
Applied, thanks!
On 05.10.21 15:14, Heiko Carstens wrote:
> On Tue, Oct 05, 2021 at 02:08:36PM +0200, Roberto Sassu wrote:
>> Fix two problems found in the strrchr() implementation for s390
>> architectures: evaluate empty strings (return the string address instead of
>> NULL, if '\0' is passed as second argument); evaluate the first character
>> of non-empty strings (the current implementation stops at the second).
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Cc: [email protected]
>> Reported-by: Heiko Carstens <[email protected]> (incorrect behavior with empty strings)
>> Signed-off-by: Roberto Sassu <[email protected]>
>> ---
>> arch/s390/lib/string.c | 15 +++++++--------
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> Applied, thanks!
>
Really? I just wanted to write a response: len is unsigned (size_t)
and compared to be >= 0, which sounds like always true.
Juergen
> From: Juergen Gross [mailto:[email protected]]
> Sent: Tuesday, October 5, 2021 3:25 PM
> On 05.10.21 15:14, Heiko Carstens wrote:
> > On Tue, Oct 05, 2021 at 02:08:36PM +0200, Roberto Sassu wrote:
> >> Fix two problems found in the strrchr() implementation for s390
> >> architectures: evaluate empty strings (return the string address instead of
> >> NULL, if '\0' is passed as second argument); evaluate the first character
> >> of non-empty strings (the current implementation stops at the second).
> >>
> >> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> >> Cc: [email protected]
> >> Reported-by: Heiko Carstens <[email protected]> (incorrect behavior with
> empty strings)
> >> Signed-off-by: Roberto Sassu <[email protected]>
> >> ---
> >> arch/s390/lib/string.c | 15 +++++++--------
> >> 1 file changed, 7 insertions(+), 8 deletions(-)
> >
> > Applied, thanks!
> >
>
> Really? I just wanted to write a response: len is unsigned (size_t)
> and compared to be >= 0, which sounds like always true.
Thanks for catching this. Will fix it.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
On Tue, Oct 05, 2021 at 01:30:45PM +0000, Roberto Sassu wrote:
> > From: Juergen Gross [mailto:[email protected]]
> > Sent: Tuesday, October 5, 2021 3:25 PM
> > On 05.10.21 15:14, Heiko Carstens wrote:
> > > On Tue, Oct 05, 2021 at 02:08:36PM +0200, Roberto Sassu wrote:
> > >> Fix two problems found in the strrchr() implementation for s390
> > >> architectures: evaluate empty strings (return the string address instead of
> > >> NULL, if '\0' is passed as second argument); evaluate the first character
> > >> of non-empty strings (the current implementation stops at the second).
> > >>
> > >> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > >> Cc: [email protected]
> > >> Reported-by: Heiko Carstens <[email protected]> (incorrect behavior with
> > empty strings)
> > >> Signed-off-by: Roberto Sassu <[email protected]>
> > >> ---
> > >> arch/s390/lib/string.c | 15 +++++++--------
> > >> 1 file changed, 7 insertions(+), 8 deletions(-)
> > >
> > > Applied, thanks!
> > >
> >
> > Really? I just wanted to write a response: len is unsigned (size_t)
> > and compared to be >= 0, which sounds like always true.
>
> Thanks for catching this. Will fix it.
I'll fix it. No need to resend.
On Tue, Oct 05, 2021 at 03:24:33PM +0200, Juergen Gross wrote:
> On 05.10.21 15:14, Heiko Carstens wrote:
> > On Tue, Oct 05, 2021 at 02:08:36PM +0200, Roberto Sassu wrote:
> > > Fix two problems found in the strrchr() implementation for s390
> > > architectures: evaluate empty strings (return the string address instead of
> > > NULL, if '\0' is passed as second argument); evaluate the first character
> > > of non-empty strings (the current implementation stops at the second).
> > >
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Cc: [email protected]
> > > Reported-by: Heiko Carstens <[email protected]> (incorrect behavior with empty strings)
> > > Signed-off-by: Roberto Sassu <[email protected]>
> > > ---
> > > arch/s390/lib/string.c | 15 +++++++--------
> > > 1 file changed, 7 insertions(+), 8 deletions(-)
> >
> > Applied, thanks!
> >
>
> Really? I just wanted to write a response: len is unsigned (size_t)
> and compared to be >= 0, which sounds like always true.
Yeah.. I did some out-of-tree tests, but of course using int instead
of unsigned int. However sparse complains also. So this wouldn't have
hit upstream.
Many thanks for pointing this out anyway!