On Wed, Mar 07, 2018 at 03:17:19PM +0200, Andy Shevchenko wrote:
> On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote:
>
> Thanks for the patch, my comments below.
(Review snipped.)
It looks pretty obvious that it'd take a lot less of your time to roll new
patch[es] from scratch than to try
On Wed, Mar 07, 2018 at 03:17:19PM +0200, Andy Shevchenko wrote:
> On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote:
>
> Thanks for the patch, my comments below.
(Review snipped.)
It looks pretty obvious that it'd take a lot less of your time to roll new
patch[es] from scratch than to try
On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote:
> Attempting to print an object pointed to by a bad (usually ERR_PTR)
> pointer
> is a not so surprising error. Our code handles them inconsistently:
> * two places print (null) if ptr * one place prints (null) if abs(ptr) * one place
On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote:
> Attempting to print an object pointed to by a bad (usually ERR_PTR)
> pointer
> is a not so surprising error. Our code handles them inconsistently:
> * two places print (null) if ptr * one place prints (null) if abs(ptr) * one place
On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote:
Thanks for the patch, my comments below.
> Attempting to print an object pointed to by a bad (usually ERR_PTR)
> pointer
> is a not so surprising error. Our code handles them inconsistently:
> * two places print (null) if ptr * one place
On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote:
Thanks for the patch, my comments below.
> Attempting to print an object pointed to by a bad (usually ERR_PTR)
> pointer
> is a not so surprising error. Our code handles them inconsistently:
> * two places print (null) if ptr * one place
On Tue, Mar 06, 2018 at 09:22:17PM +0300, Alexey Dobriyan wrote:
> > +#define BAD_PTR_STRING(x) (!(x) ? "(null)" : IS_ERR(x) ? "(err)" :
> > "(invalid)")
>
> This is getting ridiculous.
>
> Instead of simply printing a pointer as %08lx or %016llx, not only glibc
> (null) stupidity is propagated
On Tue, Mar 06, 2018 at 09:22:17PM +0300, Alexey Dobriyan wrote:
> > +#define BAD_PTR_STRING(x) (!(x) ? "(null)" : IS_ERR(x) ? "(err)" :
> > "(invalid)")
>
> This is getting ridiculous.
>
> Instead of simply printing a pointer as %08lx or %016llx, not only glibc
> (null) stupidity is propagated
> +#define BAD_PTR_STRING(x) (!(x) ? "(null)" : IS_ERR(x) ? "(err)" :
> "(invalid)")
This is getting ridiculous.
Instead of simply printing a pointer as %08lx or %016llx, not only glibc
(null) stupidity is propagated but expanded and "improved".
I assure you reading is just as
> +#define BAD_PTR_STRING(x) (!(x) ? "(null)" : IS_ERR(x) ? "(err)" :
> "(invalid)")
This is getting ridiculous.
Instead of simply printing a pointer as %08lx or %016llx, not only glibc
(null) stupidity is propagated but expanded and "improved".
I assure you reading is just as
Attempting to print an object pointed to by a bad (usually ERR_PTR) pointer
is a not so surprising error. Our code handles them inconsistently:
* two places print (null) if ptr
---
lib/vsprintf.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/vsprintf.c
Attempting to print an object pointed to by a bad (usually ERR_PTR) pointer
is a not so surprising error. Our code handles them inconsistently:
* two places print (null) if ptr
---
lib/vsprintf.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/vsprintf.c
12 matches
Mail list logo
