From: Petr Mladek <pmladek@suse.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
kernel@pengutronix.de
Subject: Re: [PATCH] printf: Emit "SUCCESS" if NULL is passed for %pe
Date: Mon, 3 Oct 2022 15:26:13 +0200 [thread overview]
Message-ID: <Yzri9bJiS46Bd1DH@alley> (raw)
In-Reply-To: <20220930140531.r6txx6ujvvbrr7hh@pengutronix.de>
On Fri 2022-09-30 16:05:31, Uwe Kleine-König wrote:
> On Fri, Sep 30, 2022 at 04:41:24PM +0300, Andy Shevchenko wrote:
> > On Fri, Sep 30, 2022 at 01:10:50PM +0200, Uwe Kleine-König wrote:
> > > For code that emits a string representing a usual return value it's
> > > convenient to have a 0 result in a string representation of success
> > > instead of "00000000".
> >
> > This is a controversial change. For APIs that comes to my mind it means
> > "OPTIONAL resource NOT FOUND, while no error happened". Doe it mean success?
> > I don't think so.
>
> OK, agreed. Would you feed such a value unchecked to %pe today (i.e.
> without my patch)?
People are primary interested into debug messages when things does
not work as expected. The check might be missing intentionally
to show all values or by mistake.
The tracepoint, used as motivation for this patch [1], is exactly
the situation where return values are printed without any check.
The problem is that %pe is used for both pointer and integer
return values. They have different semantic.
I do not feel comfortable with "improving" one use case and
breaking the other.
One solution would be to add support for "%de" but this would break
things. "%de" is supposed to print the 'e'. For example, it should
printk "123e" when the given number is 123.
Another solution would be to add modifier for the "%pe" modifier.
For example, "%ped". It would mean that the given value is in "int"
range. It could even print non-hashed value when it is out of range.
[1] https://lore.kernel.org/linux-pwm/20220916151506.298488-2-u.kleine-koenig@pengutronix.de/
Best Regards,
Petr
prev parent reply other threads:[~2022-10-03 13:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-30 11:10 [PATCH] printf: Emit "SUCCESS" if NULL is passed for %pe Uwe Kleine-König
2022-09-30 12:14 ` Petr Mladek
2022-09-30 13:24 ` Uwe Kleine-König
2022-09-30 13:42 ` Andy Shevchenko
2022-09-30 13:48 ` Uwe Kleine-König
2022-09-30 13:41 ` Andy Shevchenko
2022-09-30 14:05 ` Uwe Kleine-König
2022-10-03 13:26 ` Petr Mladek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yzri9bJiS46Bd1DH@alley \
--to=pmladek@suse.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.